Verify CLI recovery identity before wallet import

ms32 wallet could import recovered descriptors before the operator authenticated the recovered seed as the wallet they intended.

This is an accident-safety gate, not a malicious-share-tampering defense. A party able to replace a threshold of shares can already learn/spend the wallet and can deliberately manufacture human-scale identifiers.

Required restore evidence, strongest available first:

Seed-keyed encrypted descriptor backup (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 before import. This is the first-class path and the separate malicious-tampering defense.
Wallet record: accept a matching typed BIP32 master fingerprint and/or recorded single-sig descriptor checksum before import. These are human-scale second-class checks for wrong/mixed cards, miscorrection and transcription mistakes. wallet: Add checksummed recovery-record evidence #43 tracks checksummed/type-back record metadata.
No wallet record: explicitly show the recovered fingerprint and codex32/Bails identifier result, warn that the wallet has not been independently identified, and require visual confirmation before import. This must work for older backups that have no fingerprint and for Bails/Bails-alpha identifier rules.

#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 making that wallet-record/no-record decision immediately after the existing seed is parsed and before any new share ceremony or output; Ctrl-C/EOF at that early gate preserves the existing recovery cards as valid. #105/#80/#95 are the reviewed stack follow-ups needed on the same frozen runtime tip. #118 is the focused clean GUI counterpart; historical #28 duplicates obsolete library history and must not be used as the final GUI candidate. #55 remains a separate issue so accident safety is not conflated with malicious-tampering resistance.

Current remaining library/CLI order is #57 → #105 → #99 → #80 → #81 → #95. Every current head now has a current-head Codex release-gate ACK and green exact-head Python-package CI; the applicable restore/Core heads also have green Bitcoin Core fixture runs. No automated/code-review gap remains on this CLI finding. Keep this issue open through human integration of that stack and final frozen-candidate qualification.

wallet: Require the recorded fingerprint before import

First class:
The user has already selected their descriptor.gpg, they can decrypt and verify their bip85 derived signature on that to give full assurance the proper wallet this seed can sign for is restored.

Second class:
The user has their wallet record and manually types in the fingerprint, they also reentry ceremony confirmed the fingerprint during creation as it's recovery metadata.

This doesn't protect it against damage in storage however, so I still want to checksum it.
Here the wallet would not be restored until the user typed in their fp.

Under some circumstances we can skip validation and warn the wallet may not belong to them and to verify addresses, history, fingerprint, policy, balances.

If possible we can sign and encrypt the descriptor using Bitcoin Core's sign message feature. That would avoid some GPG dependency maybe.

Simple authenticated encryption may work as well for single user descriptors, GPG is most useful when coordinators need to send the finished descriptor back to the user.

Required behavior revised per #27: #57 gates CLI import on the typed fingerprint from the wallet record, and restoring without a record becomes an explicit, warned choice. Stronger verification moves to the seed-keyed encrypted descriptor backup (#55).

wallet: Check existing seed before sharing