dash-spv: checkpoint re-initialization resets filter storage but resumes download from the wallet position, manufacturing a sparse island

[QuantumExplorer]

Problem

Observed on device logs (testnet; same shape reported on mainnet). When a client that already has densely stored filters is re-initialized from a checkpoint:

19:08  🚀 Starting sync from checkpoint at height 200000 instead of genesis (requested start height: 227121)
19:08  Starting filter header sync from 200000 to 208000
19:14  Starting filter download (scan_start=1514654, download_start=1514654, stored_filters_tip=0, target=1516000)

• Filter storage previously held filters from 0 upward (stored tip ~1.13M+ in the same run).
• The checkpoint re-init reset filter storage (stored_filters_tip=0).
• The subsequent filter download resumed from the wallet's current synced position (1514654) rather than the re-init floor (200000), so heights 200000..1514653 were never (re)stored.
• Result: stored range 1514654..=tip with the client floor at 200000 — the exact sparse-island state that dash-spv: filter restart with scan_start far below stored tip loads never-populated segments — debug abort / release sentinel reads #892 / fix(dash-spv): don't preload filters below the actually stored range on filter-download start #893 dealt with downstream. Pre-fix(dash-spv): don't preload filters below the actually stored range on filter-download start #893, every later restart crash-looped in debug (SegmentCache::get_items assertion) or silently read sentinel filter data in release.

#893 makes the filter manager self-heal from any such island (one-time discard + re-download from the scan floor, verified convergent on the affected device). This issue tracks the island-manufacturer itself: after a checkpoint re-initialization that invalidates filter storage, the re-download floor and the wallet scan floor must agree — either resume storing from the re-init floor, or move the wallet/scan floor up to where storage actually resumes.

Full session-by-session log timeline available in #893 (comment) (root-cause follow-up comment).

🤖 Generated with Claude Code

[QuantumExplorer]

Refinement from the PR #893 discussion (see the timeline comment there): the island requires TWO cooperating failures — (T1) this issue: the checkpoint re-init resets filter storage and the refill resumes from the wallet's synced position instead of the new floor; AND (T2) the wallet's committed height regressing across an ABRUPT restart (evidence: session ended cleanly at committed 2504884, next session 70s later computed scan_start=200000; the persisted wallet row carries syncedHeight=2504884 today, and a restart following a long clean session resumed correctly at committed+1, while every restart following a SIGABRT/forced kill collapsed to the checkpoint floor). T1 alone yields a consistent state. T2 appears to live in the embedding app / platform-wallet sync-height persistence cadence, tracked separately on the dashpay/platform side.

🤖 Generated with Claude Code