Android seed encryption and plaintext migration

[DevAnuragT]

Body:

Context

Android production currently stores the wallet mnemonic in plaintext:

• seed_phrase is read and written by NodeService.
• StabilityProcessingService reads the seed during unattended background processing.
• AppState checks seed_phrase and legacy keys_seed.
• PR feat(android): implement secure keystore seed encryption and settings-based biometric gate #142 added KeystoreEncryptionService, but it was closed and is not wired into production.
• The existing helper requires user authentication, which is incompatible with background processing.

Proposed design

1. Encrypt seed_phrase with AES-256-GCM.
2. Store the encryption key in Android Keystore, without interactive user authentication.
3. Use StrongBox when available, with a TEE/software fallback.
4. Introduce one seed-storage abstraction used by NodeService, StabilityProcessingService, and AppState.
5. Migrate in stages:
   • Shadow-write seed_encrypted; keep plaintext authoritative.
   • Read encrypted storage first, with plaintext fallback.
   • After validation, verify decrypt success and delete seed_phrase.
6. Preserve keys_seed migration support.
7. Delete seed_encrypted and the Keystore key during wallet reset.

Required invariants

• Never delete plaintext before a successful encrypted write and verified decrypt.
• Never generate a replacement key when encrypted data already exists.
• Decryption failure must not silently start a different wallet.
• Background services must decrypt without user interaction.
• Do not log seed material or include it in telemetry.

@toneloc Please review the Android storage design, migration behavior, failure handling, and phased rollout before implementation begins.

[toneloc]

The design is sound and matches common wallet practice: use a non-exportable Android Keystore key, AES-256-GCM, no interactive authentication for background processing, and StrongBox with TEE fallback.

Before implementation, I would make these requirements explicit:

• Encrypted storage is authoritative whenever it exists. If seed_encrypted exists but its key is missing, invalid, or decryption fails, stop with a recoverable error. Never generate a replacement key or wallet.
• Do not overwrite an existing encrypted seed from plaintext. If encrypted and plaintext values differ, fail visibly rather than choosing either.
• Make migration crash-safe. Write a versioned envelope containing the IV and ciphertext/tag to a temporary file, commit/fsync, atomically rename, decrypt it, and compare the recovered mnemonic before deleting plaintext.
• Prevent concurrent migration/reset. NodeService, StabilityProcessingService, and AppState should use one repository plus a process-safe lock.
• Handle StrongBox explicitly. Retry key creation without StrongBox only for StrongBoxUnavailableException; do not broadly catch errors and regenerate keys.
• Exclude encrypted seed files from Android Auto Backup/device transfer. The Keystore key will not necessarily transfer, leaving undecryptable ciphertext on the restored device.
• Treat reset failures as failures. Stop background processing first, delete the encrypted blob and Keystore alias, verify absence, and only then report reset complete.
• Do not promise secure erasure of the old plaintext. Flash storage cannot guarantee physical erasure; deletion only prevents normal future access.
• Log only stable error categories, never the mnemonic, ciphertext, IV, or derived identifiers.

Suggested rollout remains appropriate: shadow-write → encrypted-first reads with plaintext fallback → verified decrypt → plaintext deletion in a later release.

Acceptance tests should cover interrupted writes, tampered ciphertext/tag, missing or invalidated keys, concurrent foreground/background access, reboot-before-first-unlock, failed plaintext deletion, keys_seed migration, reset failure, and backup restoration.