Stabilize transaction-log purge blast-radius coverage

[kriszyp]

Summary

Stabilizes QA-782 without weakening its RocksDB stress arm. The apparent lost KEEP/CTRL reads were test-cascade failures: on failing Windows jobs, LMDB seeding timed out before those records existed; completed seeds read correctly on every covered surface, and the installed/locked RocksDB binding is 2.7.1 rather than the older affected release.

• keep the RocksDB subject at 6,000 deleted plus 6,000 retained rows and require more than 16 MiB of transaction-log data
• reduce only the LMDB control to 600 rows per range, since it does not exercise RocksDB transaction-log rotation
• fail later phases closed unless the complete seed, control row, flush sequence, and disk preconditions succeed
• match only the target ID's exact pre-cutoff insert audit entry
• probe the deleted-record subject before exercising a known-present control across all five absence detectors

This is a test defect, not a product data-loss defect. Main failures show the seed phase timing out first, followed by requests for keys that phase never created; a successful main job with completed seeds passes the same ordinary-read checks for both engines.

Evidence

• Windows failure: LMDB seed times out, then k11999 is absent
• Windows failure: seed fetch aborts before k9000/ctrl0, plus the audit-matcher false failure
• Windows success: both completed seeds and all read surfaces pass

Verification

• npm run build

• seven targeted QA-782 runs during development, each 14/14 across RocksDB and LMDB; RocksDB continued to produce 21.182 MiB of .txnlog data

• deliberate oracle mutant: a known-present ctrl0 was temporarily routed through the deleted-record probe; both engine arms failed in phase 4 (12/14), then the mutation was removed and the suite returned to 14/14

• npm run lint:required

• npm run format:write (no changes)

• full integration run reached QA-782 under concurrent suite load, but the aggregate command remained red on unrelated real-Ollama tests

• local unit aggregates are not authoritative on this host: test:unit:main initializes an installed system database before test path overrides, while test:unit:resources exposed installed config/state differences

• PR-triggered run 32370864136: all six Windows Node 24 shards passed. Shard 1 ran both QA-782 arms successfully; RocksDB produced 37.177 MiB of .txnlog data and LMDB seeded in 8.4 seconds. The aggregate workflow's only failure was the adjacent QA-431 lost-increment assertion on uWS shard 3.

• Repeated run 32370882792: the entire workflow passed, including all six Windows Node 24 shards. Shard 1 again ran both QA-782 arms successfully; RocksDB produced 37.177 MiB and LMDB seeded in 12.2 seconds.

Human reviewer decision

Please confirm the engine-specific volume choice: LMDB uses 600 rows per range while RocksDB retains 6,000. Equal volume would restore parity, but it also restores the Windows timeout that caused the false cascade and does not strengthen the RocksDB-only rotation invariant. This is reversible by changing one constant.

Co-Authored-By: GPT-5 Codex noreply@openai.com

_{Review-Coverage: authored=codex; ran=gemini; adjudicated=domain; declined=claude,cursor-grok,cursor-composer; rounds=3 @ 7d8c58c}

_{Human-Review-Need: 3 (decisions: lmdb-reduced-volume) @ 7d8c58c}

[gemini-code-assist]

Code Review

This pull request refactors the stale-read blast radius integration test to dynamically scale the test volume based on the storage engine, reducing the workload size for LMDB while maintaining the larger stress volume for RocksDB. It introduces a helper function isPreCutoffInsert to refine audit log filtering, adds assertions to ensure the seeding phase completes before subsequent probes, and implements a positive control check to validate the absence detector. No review comments were provided, so there is no additional feedback.

[claude]

Reviewed; no blockers found.