Verify CLI recovery identity before wallet import

[BenWestgate]

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:

1. 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.
2. 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.
3. 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. #28 is the GUI counterpart. #55 remains a separate issue so accident safety is not conflated with malicious-tampering resistance.

[BenWestgate]

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.

[BenWestgate]

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).