[droplister]

Summary

• split the burn-address special case from ordinary address activity lookups so D1 can seek idx_burns_source
• stop rewriting raw R2 transaction objects during recovery reclassification
• add regression tests for the SQLite query plan and R2 persistence behavior

Production measurement

For an ordinary address on the live core database:

• before: SCAN burns USING COVERING INDEX idx_burns_source, 2,577 rows read
• after query: SEARCH burns USING COVERING INDEX idx_burns_source (source_id=?), 0 rows read
• result parity: both returned the same irst_block / last_block

For the Counterparty burn address, the explicit full-burn query returned the same bounds as the previous OR query (278319–283810).

The old query ran about 86,000 times and read about 222 million rows in the prior 24-hour sample. The new plan removes the full burn-index scan for every ordinary address.

Recovery reclassification already GETs each canonical raw transaction from R2. Passing persistRawTransactions: false removes the redundant PUT while preserving default persistence for scanner/import calls. At a full 50-transaction batch every two minutes, this avoids up to 36,000 R2 writes/day while the backlog is active.

Verification

pm test -w xcp-api: 468 passed, 0 failed (34 live-contract tests skipped by design)

pm run check: typecheck, ESLint, Prettier, and structure checks passed