test: reproduce the reopened-rescan livelock in the pool-healing path

[zancas]

This PR adds one deterministic unit test that demonstrates a livelock in the healing path introduced by the base branch, plus the two-line mock repair the test needs. The test fails on this branch by design; it passes once the healing is fixed.

The cycle it demonstrates

reopen_pool_history clears the condemned pool's shard tree and returns its scanned ranges to Historic, but it leaves the condemned wallet blocks in the block store, and their tree_bounds still carry the zeroes that triggered the reopening. The rescan then dispatches adjacent Historic chunks to both scan workers (Historic outranks Scanning in the priority order, so the second worker does not idle). create_scan_task seams the second chunk on the surviving stale block below it, and InitialScanData::new trusts that seam's bounds over the chain metadata served with the compact blocks. The second chunk therefore fails check_tree_size on its first block, in milliseconds, with the exact IncorrectTreeSize that caused the reopening — while the first chunk still has its full trial-decryption workload ahead. The fast failure is processed first: the wallet reopens the same history again and the session ends, discarding the slow chunk's work. The next session reconstructs the identical race, so the healing never completes for any reopened history that spans more than one chunk.

The test drives one full turn of that cycle without timing or concurrency: it fabricates the post-reopening sync state that reopen_scan_ranges_from produces, issues the two create_scan_task dispatches the two workers would receive, scans the second chunk from its attached seam, and asserts that the scan does not reproduce the reopening error. On this branch it panics with:

the reopened rescan reproduced the reopening error (Ironwood history recorded 5
where the chain reports 105): reopening recreates this exact state, so the
healing loop never completes

The branch's end-to-end tests cannot observe this because their regtest histories fit inside a single chunk, so no rescan chunk is ever seamed on a condemned block.

Candidate fixes

Either of these makes the test pass. First, have reopen_pool_history also strip or revoke the reopened pool's bounds in the surviving wallet blocks, so no future seam can trust them — the branch's own strip_pool_tracking_for_test already implements exactly this cut. Second, teach the seam-trusting arm of InitialScanData::new to fall back to calculate_block_tree_bounds for a pool whose seam testimony is condemned.

Incidental repair

MockWallet gains a real (empty) transparent-address store because create_scan_task reads it and both getters were todo!() stubs.

🤖 Generated with Claude Code

[Oscar-Pepper]

this seems like over-kill, I dont think the right solution is to add so much unecessary new fields and logic, especially adding to serialization. From what i understand, the issue this PR is trying to solve is the fact that the wallet block with the incorrect ironwood tree bound still persists in the wallet after the IncorrectTreeSize error is hit and the scan range is set back to historic for rescanning. It is true this error can be hit again as it wont necesarily be scanned in linear order and we can't use verify scan priorities for this purpose, meaning we cannot guarantee linear scanning. I believe the correct approach is to just remove any wallet data in the ranges that were reset and add the heights of all removed txs as scan targets so these txs are priorities and also definately not missed during rescan

[zancas]

Data written by a writer that doesn't know how to interpret the data (because it's from the writer's future) cannot be known to be correct.

The specific instance is not the correct thing to fix.

The thing to fix is to make the system aware of how the input data is evolving and make it impossible for this class of errors to ever recur.

[Oscar-Pepper]

i propose we solve this issue with this #2607 instead