Preserve AiDex pairing keys across reconnects

[ctqvva]

What changed

• Treat the AiDex PAIR credential as stable until a confirmed sensor-side DELETE_BOND acknowledgement.
• Store validated keys synchronously in two independent app-private preference files, keyed by canonical serial, and migrate the legacy 5e488fa5 preference when present.
• Reconnect with the saved PAIR key by reading a fresh F002 BOND/session vector; never request F001 during normal reconnect.
• Retain the last-known-good key on decrypt, CRC, GATT, timeout, reset, local forget, and Android bond failures.
• Retry saved-key reconnect through a clean GATT connection at most three times, then preserve the key and fall back to broadcasts.
• Permit one fresh F001 exchange only for a connection that began unbonded. An existing bond without a recoverable key now falls back to broadcasts instead of probing PAIR.
• Promote a newly received key only after a valid, CRC-checked direct F003 glucose frame.
• Remove automatic Android-bond deletion from setup recovery and preserve the bond/key across CLEAR_STORAGE reset.
• Clear stored credentials only after an explicit unpair receives a successful sensor acknowledgement.
• Add a 48 dp icon-only key backup button between Reset and Unpair, with a credential warning and system document picker.
• Add backup import to the AiDex setup wizard for cross-device migration; imports are checksummed and cannot overwrite a different stored key.
• Localize the new backup/restore UI in every shipped locale.

Why

The earlier 5e488fa5 implementation treated a failed saved-key F002 decrypt as proof that the stable PAIR key was invalid, deleted it, and retried the full F001 PAIR flow. It also coupled several transport/bond recovery paths to key deletion or Android bond removal. A transient reconnect failure could therefore turn into repeated sensor-side pairing traffic and strand an otherwise usable sensor.

This version deliberately chooses degraded broadcast connectivity over a speculative/destructive pairing recovery.

Verification

• :Common:processMobileLibre3SiDexGoogleDebugResources
• Focused PAIR backup and reconnect-policy tests
• Full tk.glucodata.drivers.aidex.native.* unit-test package
• Kotlin/Java compilation for mobileLibre3SiDexGoogleDebug
• XML validation for every changed locale
• git diff --check

All checks passed locally.

Hardware validation boundary

This is source-, resource-, and unit-test verified, but not yet validated against a live AiDex sensor. Keeping this PR as draft until a saved-key reconnect, reset, explicit unpair, export, and restore cycle is exercised on hardware.

Backup-file note

The portable .aidexkey file intentionally contains the sensor credential so it remains restorable on a different device; the UI warns the user to store it privately. Android Keystore encryption is not used for the portable copy because Keystore keys are device-bound and would make a migrated backup unreadable.