Review fixes for #909: generation guard, surfaced record rewrites, restored public API

[QuantumExplorer]

Review fixes for dashpay#909

Two commits addressing findings from review of dashpay#909, targeting this PR's branch so they land as part of it. All findings were independently verified against the code before fixing.

Round 1 (aac1bd99)

• Gate the net_amount recompute in compensate_for_observed_spends: only replace the match-derived net_amount when the compensation actually dropped an output detail, keeping the no-observed-spend path byte-identical to pre-bug: out-of-order block processing causes SPV wallet to miss UTXO spends dashpay/rust-dashcore#649 behavior. Pinned by a new unit test.
• Report observed-spend map growth as a state modification: record_observed_spends now returns whether the persisted map changed and check_core_transaction surfaces that via state_modified — a consumer persisting only on reported modifications must not lose a recorded spend across a restart (that would reopen bug: out-of-order block processing causes SPV wallet to miss UTXO spends dashpay/rust-dashcore#649 for the coin). Pinned by a new regression test.
• Replace a comment reference to a nonexistent test with the inline rationale.
• Tighten MAX_OBSERVED_SPENT_OUTPOINTS 10M → 1M (load-time allocation cap from ~hundreds of MB to ~tens of MB).

Round 2 (aa250e49) — external review findings

1. [P1] Generation guard for mid-flight account adds. The height-only contiguity guard could still certify unscanned coverage: a rewind landing inside a scanned batch's range passes the height check (scan [5000..9999] at 9000, rewind to 7499 → committed to 9999), and an account add that moves no heights (checkpoint already at the birth floor) is invisible to any height comparison. ManagedWalletInfo now carries an in-memory account_generation bumped on every account add — even height-invisible ones; scan_batch snapshots it per wallet (FiltersBatch.scanned_wallets is now a wallet → generation map, captured under the same read lock as the behind-set) and commit refuses to advance any wallet whose generation changed since scan. The wallet stays behind and the tick rescan picks it up. Pinned by three new dash-spv tests including both repro shapes.

2. [P2] Surface guard-rewritten funding records. remove_spent_from_accounts rewrote funding records (compensation) without emitting them; on the unmatched path the result returned is_relevant == false, so downstream persistence could retain the stale +value record. It now returns post-compensation clones, the checker emits them as updated_records on both the relevant and irrelevant paths, and WalletManager propagates updated_records independent of is_relevant. The compensation itself is kept: it is what keeps aggregate history consistent with in-order processing — the defect was the silent mutation.

3. [P2] Restore the public account API. ManagedAccountRefMut::record_transaction/confirm_transaction had gone pub → pub(crate) with changed signatures on a publicly re-exported type. The public methods are restored with their original signatures (recording with no observed-spend context — the pre-bug: out-of-order block processing causes SPV wallet to miss UTXO spends dashpay/rust-dashcore#649 behavior for callers driving an account directly); the wallet checker uses new pub(crate) *_with_observed_spends variants.

Verification

• key-wallet lib: 557 passed / 0 failed (4 new tests)
• key-wallet-manager: all suites pass, incl. the three bug: out-of-order block processing causes SPV wallet to miss UTXO spends dashpay/rust-dashcore#649 integration tests
• dash-spv lib: 485 passed / 0 failed (3 new generation-guard tests)
• dash-spv dashd_sync (live dashd regtest): 29 passed / 0 failed
• cargo fmt clean; cargo clippy --all-features --all-targets clean on all three crates; key-wallet-ffi / dash-spv-ffi compile

🤖 Generated with Claude Code