repro: ironwood tree-size truncation clears sapling and orchard trees

[dorianvp]

Claim

truncate_to_pool_activation_height in pepper-sync/src/sync.rs (lines 1626 to 1712) selects the shard trees to clear with if target_pool >= pool (line 1674). ShieldedPool derives Ord as Sapling < Orchard < Ironwood, so an Ironwood target clears the Sapling, Orchard and Ironwood trees. The doc comment on the function (lines 1620 to 1625) says that the target pool and any later pool are cleared and that earlier pools only roll back to the next checkpoint above the rescan height.

The cleared trees are reseeded with the frontier at the wallet birthday (lines 1662 to 1685). Scan ranges are reopened from rescan_from = max(activation, birthday) by state::reopen_scan_ranges_from (line 1704). When the birthday is below the NU6.3 activation, the sapling and orchard leaves in [birthday, rescan_from) are removed from the trees and their scan ranges remain Scanned, so they are never rebuilt. This is a witness loss for notes received in that window.

What the test does

sync::test::pool_activation_truncation::ironwood_truncation_keeps_sapling_and_orchard_leaves_below_activation builds a MockWallet on a LocalNetwork with NU6.3 activation at height 100 and a birthday of 10. The sapling and orchard shard trees hold one leaf per height from 10 to 20 with checkpoints. The scan ranges 10..50 and 50..150 are Scanned. A fake fetcher answers the FetchRequest::TreeState request with an empty tree state at the requested height. The test calls truncate_to_pool_activation_height with target_pool = ShieldedPool::Ironwood and asserts the documented behaviour: the scan ranges below rescan_from stay Scanned and the sapling and orchard trees keep their leaves.

Observed failing output on dev

thread 'sync::test::pool_activation_truncation::ironwood_truncation_keeps_sapling_and_orchard_leaves_below_activation' panicked at pepper-sync/src/sync.rs:3905:13:
assertion `left == right` failed: ironwood truncation cleared the sapling tree: leaves in [birthday, rescan_from) are gone and their scan ranges remain Scanned
  left: None
 right: Some(Position(10))

The scan range assertion passes, which confirms that the ranges below the rescan height are still Scanned while the sapling tree no longer has any leaves.

This PR is a reproduction and is not a fix. The sync-bench A/B rule was not run because the commit adds a test only.

🤖 Generated with Claude Code