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. #28 is the reviewed historical GUI implementation of the same accident-safety boundary, but must not be merged as the final GUI candidate because its old branch duplicates library history.

Current library/CLI integration order is #42 → #46 → #57 → #80 → #81. #46 now deliberately precedes #57 because the behavior-preserving cleanup keeps the maintainer-authorized <5200 installed-source gate satisfied at every intermediate commit; #57 directly on #42 exceeded that budget. #80 is refreshed directly onto #57. #81 remains the final early-record-gate follow-up and must be refreshed directly onto #80 before human review.

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 only #28's reviewed GUI restore-authentication delta onto that tip. Do not preserve #28's duplicated library snapshot or exploratory history. 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.