gui: Require wallet identity before restore

[BenWestgate]

What and why

A checksum-valid recovered seed may still be the wrong wallet. The GUI formerly reached wallet selection and import before presenting a fingerprint. This change asks for the fingerprint from the separate wallet record before listing wallets, carries it through every restore destination, and rechecks it before unlock, wallet creation, and library import. The explicit no-record route shows the recovered fingerprint and identifier assessment, then requires Restore anyway. Once disclosed, this attempt cannot return to the recorded-fingerprint route.

This is accident safety against wrong or mixed cards, not resistance to malicious replacement of a threshold of shares. The seed-keyed encrypted descriptor backup in #55 is the separate human-planned tampering defense.

Fresh creation still records its new fingerprint without claiming a pre-existing wallet identity. The separately enforced GUI budget rises from under 2,050 to the authorized under 2,250 lines; the current GUI is 2,177 logical lines. Small Python 3.10 compatibility adjustments are necessary because the integrated library supports 3.10 through 3.15.

Review scope and integration

This is one focused commit relative to a disposable staging base that merges the existing #78 GUI tip with the #33 library tip. No existing PR branch was rewritten. Review this diff for the GUI restore gate; do not merge the staging base directly to reviewability-v1. Historical #28 contains an obsolete copy of the library; this PR is the clean GUI replay. After upstream branches settle, a human can carry this GUI commit onto the final integration tip. Refs #26 and #28.

Verification

• 1,062 normal tests and 1,062 optimized tests pass on this combined tip.
• Focused Core mismatch-before-wallet-RPC, GUI mismatch-before-unlock, route, and verify-before-create tests pass.
• Ruff lint/format, strict mypy for library and GUI, and git diff --check pass.
• The repository regtest fixture passes on this exact tip with the checksum-verified official Bitcoin Core v32.0rc2 binary (Satoshi 32.0.0). This exercises the Core import/relock/rescan path; it is not a manual GUI-to-Core walkthrough.
• The stubbed Xvfb walkthrough passes the new unseen-record, no-record disclosure, explicit confirmation, and stop-without-wallet-listing checks. Two unrelated card-grid alignment checks fail identically on untouched gui: Let the home window choose its height #78, so the overall walkthrough is not green. Final rendered Tails and manual GUI-to-Core qualification remain for the integration candidate.

AI assistance produced this draft. It remains draft for human review, authorship, and signed integration under the repository AI policy.

[BenWestgate]

AI-generated review (Codex), posted at the maintainer's request.

Not ACKing d5b671a yet: the restore gate looks correctly threaded through GUI and library, but this raises the GUI review budget to 2,250 without explicit authorization.

[BenWestgate]

AI-generated current-head follow-up review (Codex), posted at the maintainer's request.

ACK d5b671a5c24b for the focused GUI restore-identity delta.

The earlier NACK treated the GUI <2250 review budget as unauthorized. The central release tracker #38 now explicitly records the maintainer-approved separate GUI cap of <2250 and the current GUI measures 2,177 logical lines, so that review blocker is stale.

The restore gate itself was already reviewed as correctly threaded: recorded identity is checked before wallet selection/unlock/import, the no-record route discloses the recovered identity only after that explicit choice, and restore rechecks identity immediately before a new Core destination is created. The exact combined staging tip reports normal/optimized suites, focused mismatch-before-wallet/unlock tests, real-Core fixture coverage, Ruff/mypy, and the Xvfb identity-path checks.

This ACK is for the focused #118 delta. Final integration still requires replaying it onto the settled #65 → #66 → #77 → #78 → #119 GUI stack and completing the documented Tails/manual visual qualification. Human review/authorship policy still applies.

[BenWestgate]

@codex review

[chatgpt-codex-connector]

Codex Review: Didn't find any major issues. Breezy!

Reviewed commit: d5b671a5c2

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[BenWestgate]

Codex current-head review at d5b671a: one existing P2 remains. Fresh backup still advances after “I wrote it down” without requiring the wallet-record fingerprint to be re-entered and verified, unlike the share read-back flow.

[BenWestgate]

AI-assisted current-head review, posted at the maintainer's request.

ACK f871e59. Fresh creation now blocks wallet selection until the recorded fingerprint is re-entered, parses, and matches; the new boundary test covers that gate. Exact-head package CI passes. Final Tails/manual GUI qualification remains pending.

[BenWestgate]

AI-assisted current-head review: ACK f871e59. Recorded restores verify the typed wallet-record fingerprint before wallet listing and carry that expected value through unlock/create/import, with another verification immediately before mutation. The explicit no-record route is clearly separated, discloses the recovered identity, requires Restore anyway, and cannot return to the recorded-fingerprint route in the same attempt. Fresh creation only re-enters its newly generated fingerprint as a record-writing check, correctly passing no pre-existing identity commitment. Exact-head Python-package CI is green and there are no unresolved review threads. Final supported-Tails rendering and manual GUI-to-Core qualification remain integration checks, not code-review blockers.