feat(storage): reclaim disk safely during live queries

[mo4islona]

Summary

• run whole-file disk reclaim periodically at runtime, while queries remain active
• keep point tombstones and persist their RocksDB sequence in DELETED_TABLES
• compare each purge sequence with rocksdb.oldest-snapshot-sequence, so only pre-delete snapshots pin files
• serialize reclaim with table-id allocation, without putting query snapshots behind a global gate
• extend CT7 churn diagnostics with continuous query pressure

Safety model

Deletion records now move through DeleteRequested -> PurgedUnstamped -> Purged(sequence). Empty legacy values still decode as DeleteRequested, so no migration is needed. The unstamped state makes a crash between the tombstone batch and sequence stamp recoverable and fail-closed.

Runtime reclaim takes one consistent metadata snapshot, computes a watermark from live tables, dirty builds, and deletion records still visible to the oldest snapshot, then calls DeleteFilesInRange. Once a purge sequence is older than every live snapshot, that fact is monotonic: future snapshots cannot become older.

This keeps the snapshot-safe point-delete mechanism from #84 and does not introduce DeleteRange or a compaction filter.

Verification

• cargo test -p sqd-storage
• cargo test -p sqd-hotblocks-harness
• cargo test -p sqd-hotblocks --tests
• cargo test -p sqd-hotblocks --test ct7_stall_and_churn ct7_churn_soak -- --ignored
• cargo clippy --no-deps -p sqd-storage -p sqd-hotblocks-harness -p sqd-hotblocks --all-targets
• cargo +nightly fmt --all -- --check
• git diff --check

The CT7 soak ran periodic reclaim every 2 seconds while two clients continuously queried the moving retention window.