wallet: make corrupted transaction records fail wallet loading instead of forcing a rescan #35760

In wallet loading, the NEED_RESCAN enum was only ever returned if the stored hash of a transaction did not match the calculated hash of the transaction. This would then trigger a rescan from genesis during loading, and then allow the wallet to be operational as if it were normal.

However, it seems incorrect to be treating such corruption as acceptable. That transaction would be inserted to mapWallet, but not be added to mapTxSpends or any of the conflict tracking or to TXO caching. Furthermore, the rescan doesn't actually fix the problem, the incorrect record would persist, which means that the wallet would be rescanning the entire chain every time it is loaded. The only situation this could occur is if the wallet actually experienced corruption, so it's reasonable to return CORRUPT instead and force the user to load a backup or otherwise un-corrupt the wallet before it can be used.

Implements the idea from #35501 (review)

<!--e57a25ab6845829454e8d69fc972939a-->

The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

<!--006a51241073e994b41acfe9ec718e94-->

Code Coverage & Benchmarks

For details see: https://corecheck.dev/bitcoin/bitcoin/pulls/35760.

<!--021abf342d371248e50ceaed478a90ca-->

Reviews

See the guideline and AI policy for information on the review process.

If your review is incorrectly listed, please copy-paste <code>&lt;!--meta-tag:bot-skip--&gt;</code> into the comment that the bot should ignore.

<!--174a7506f384e20aa4161008e828411d-->

Conflicts

Reviewers, this pull request conflicts with the following ones:

• #27865 (wallet: Track no-longer-spendable TXOs separately by achow101)

If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first.

<!--5faf32d7da4f0f540f40219e4f7537a3-->

Approach ACK at fdd1a439fbf462c5d0fbfa2c4b7ac7f9c9a33a15

When a tx record's stored hash doesn't match the hash of its deserialized content, returning NEED_RESCAN was the wrong response: the rescan is not a reliable repair — it only overwrites the corrupted DB record as a side effect if the tx happens to be on-chain and wallet-relevant; if it isn't, the corrupted record stays in the DB permanently and the wallet rescans from genesis on every subsequent load. I think failing hard with CORRUPT makes no unverifiable assumptions about what the DB was supposed to contain, and signals unambiguous failure rather than attempting an unreliable recovery.

Having said that, the error message "Error loading %s: Wallet corrupted" gives the user no indication of what to do next.

Since this is a user-visible behaviour change — wallet now fails to load instead of triggering a rescan — some release note seems required.

As a side effect, bitcoin-wallet info on a wallet with this corruption previously printed a misleading "Rescanning wallet" warning to stdout and silently exited with an error code — the tool never calls AttachChain so no rescan would ever run. It now correctly prints "Wallet corrupted" to stderr (but still no indication to the user of what to do next).

One suggestion: a unit test that writes a tx record with a mismatched key to the DB and asserts loading fails with CORRUPT would pin this behaviour and prevent regressions. I have one ready at 5e3212293b on top of this PR if useful.

The PR correctly surfaces the corruption at load time rather than silently rescanning forever. The missing piece for users is what to do when they see that error — opened #35944 which adds a "Recovering from a Corrupted Wallet" section to doc/managing-wallets.md to address that gap.

Also worth noting: walletdb.cpp:1050 has an error message that still says "This can be fixed by removing transactions from wallet and rescanning." — that message covers a different corruption path but contradicts the same user-facing guidance. Could be addressed here since this PR is already touching the corruption detection code.