Verify recovered wallet identity before import

[BenWestgate]

Accident-safety finding. src/codex32_gui/pages.py::_record() could import private descriptors before the restore flow authenticated the recovered seed as the wallet the operator intended.

Required behavior before any wallet mutation:

1. First-class evidence: if the operator has the seed-keyed encrypted descriptor backup tracked in wallet: Encrypted descriptor backup keyed by the seed #55, decrypt it with the recovered seed and require the recovered seed to match the backed-up single-sig descriptors.
2. Second-class recovery record: otherwise accept a matching typed master fingerprint and/or the recorded single-sig descriptor checksum. These are human-scale accident checks, not a defense against a malicious party who can replace a threshold of shares.
3. No wallet record: explicitly offer a fallback that displays the recovered fingerprint plus the codex32/Bails identifier result, then asks the operator to confirm before import. This is deliberately a visual accident check because older/Bails backups may not have a recorded fingerprint and Bails alpha used a different identifier rule.

#57 implements the current release-gate subset for the CLI/library: typed fingerprint plus explicit no-record fallback, with the check enforced before wallet mutation. #81 strengthens ms32 create --existing by moving the record/no-record decision before any new share ceremony. #118 is the focused clean GUI replay of the same accident-safety boundary. Historical #28 must not be merged because its old branch duplicates library history.

#42 is integrated into reviewability-v1. The remaining library/CLI integration order is #57 → #105 → #99 → #80 → #81 → #95. All five current heads have current-head Codex release-gate ACKs; their exact-head Python-package runs are green, and the applicable restore/Core heads also have green Bitcoin Core fixture runs. #105/#80/#81/#95 are agent-authored follow-ups and still require the repository's responsible-human rewrite/squash step before integration.

Final GUI integration: after that library/CLI candidate and the remaining foundation/security/API work settle, rebase the clean GUI stack once in order #65 → #66 → #77 → #78, then replay/squash the single focused GUI restore-authentication commit from #118 onto that tip. Do not merge the disposable staging base used by #118 or preserve the duplicated library snapshot and exploratory history from #28. Run the supported Tails guest-resolution/manual qualification, including the unresolved #76 artwork observation, and then include the GUI in the fresh adversarial review.

#43 tracks checksummed/type-back wallet-record metadata. #55 separately tracks the stronger encrypted-descriptor evidence and malicious-tampering defense; it requires human planning/review before implementation rather than an automatic PR.

[BenWestgate]

I agree. The software should either verify the wallet from the descriptor or encrypted descriptor backup (meaning it's encrypted/signed by a key the valid master node derives), request the fingerprint be entered (useful for QR + passphrase share recoveries w/ inadequate salt and error detection), or display the fingerprint for user confirmation.

Even if the I don't have a fingerprint case, I'd still show it first and ask if this was it before guessing the wallet is right.