[Investigation] Wallet records can outlive their secure seed

[BullishNode]

Summary

The wallet database can contain default-wallet rows while the corresponding seed is absent from secure storage. When this happens, the wallet bootstrap path treats the existing rows as sufficient and returns without validating that the seed is available.

The wallet then appears to exist, but any operation that derives from its seed fails later with a seed-not-found error.

Concrete failure path

1. Default wallet records already exist in the local database.
2. The corresponding seed entry is missing from secure storage.
3. CreateDefaultWalletsUsecase sees the existing wallet records and returns them without checking seed availability.
4. A later seed-derived operation requests the seed by fingerprint.
5. The operation fails because the seed is unavailable.

Affected operations can include BIP85 derivation, Lightning Address wallets, invoice wallets, Donation Pages, Point of Sale wallets, and wallet metadata backup/recovery.

Why this needs investigation

The application currently has two possible sources of truth for wallet existence:

• the local wallet database
• secure seed storage

They can disagree. The resulting state is especially problematic because the wallet is presented as available until a later operation needs the seed.

Possible causes include secure-storage loss, an interrupted migration or restore, partial cleanup, or wallet/database lifecycle operations completing in different orders.

Questions

• Is a database wallet row without its seed a valid supported state?
• Should wallet bootstrap validate seed availability before returning existing wallets?
• If a recovery mnemonic is supplied, should bootstrap repair the missing seed?
• If repair is impossible, should the wallet be hidden, quarantined, or reported as unavailable?
• Are wallet creation, deletion, migration, and restore operations atomic across the database and secure storage?
• What user-facing error should be shown when the seed cannot be recovered?

Desired outcome

Define and implement the invariant between wallet database records and secure seed storage so that the app cannot silently expose a wallet as usable when its seed is unavailable. Add coverage for secure-storage loss and interrupted or partial wallet lifecycle operations.

This remains an investigation until the intended behavior for this inconsistent state is confirmed.

[BullishNode]

Follow-up from the QA run: with explicit fixture-seed provisioning before wallet creation, the original 8 metadata round-trip cases now pass in fresh app processes. This confirms the original SeedNotFoundException was caused by test-state/setup ordering rather than the metadata feature requiring a missing production seed. The investigation remains open for the broader startup invariant: whether wallet rows can legitimately outlive secure seed material, and whether startup should validate or repair that state.