fix(query-engine): exact-window queries take a read lock, not write

[milindsrivastava1997]

Summary

• MutableEpoch::exact_query needed &mut self solely to lazily build/cache its window_to_ids offset index, forcing per_key.rs's exact-query call site to take a full write lock on the per-aggregation shard even though the queried data itself isn't mutated — serializing exact-window queries against every other concurrent reader/writer of that shard.
• window_to_ids now lives behind its own RwLock, independent of the outer shard lock. exact_query takes &self and builds the index lazily under double-checked locking (read fast path; write + re-check slow path). insert/remove_windows still invalidate it at zero cost via get_mut() — no lock acquired, since &mut self already proves exclusive access there.
• per_key.rs's call site drops from .write() to .read() — this is the actual concurrency fix (real RwLock-backed shard, the default LockStrategy).
• global.rs is updated to compile against the new signature (get_mut → get) but has no locking change — it uses a single Mutex for the whole store with no read/write split, so there's nothing to fix there.
• legacy/ store implementations are untouched — confirmed dead code (unreachable via LockStrategy, no references anywhere outside legacy/ itself).

Testing

Test coverage was designed by a separate agent given only the problem description (not this fix), working from an isolated worktree checked out at the pre-fix commit, specifically to avoid biasing the tests toward this implementation's shape.

• 5 correctness tests added to the existing run_contract_suite (run against both LockStrategy::PerKey and ::Global): stability across repeated calls, no shadowing of a later insert by an earlier cache build, miss-then-hit after insert, 900 interleaved insert/query rounds checked by value, and correctness across epoch rotation.
• 1 concurrency test (test_exact_query_does_not_block_concurrent_range_queries_per_key), written as a TDD red test asserting the desired fixed behavior: a concurrent range query's max latency should stay under 20% of a forced index-rebuild's duration. Pre-fix, this failed cleanly and consistently (reader latency ≈ exact-query duration, ratio ~1.00 across repeated runs) — a reader visibly blocked for the full write-lock hold. Post-fix, it passes.

Fixes #607.

Test plan

• cargo test -p query_engine_rust --lib — 576 passed, 0 failed
• cargo test -p query_engine_rust --lib store_correctness_tests — contract_per_key, contract_global, and the new concurrency test all pass
• cargo fmt / cargo clippy clean (pre-commit hooks passed)

🤖 Generated with Claude Code

[milindsrivastava1997]

Code Review

Reviewed the core change (scoping exact_query to a read lock instead of write) across common.rs, global.rs, per_key.rs, and the new correctness tests. The locking logic is race-free and the exclusive/shared lock split between insert/remove_windows and exact_query is correct for both PerKey and Global stores. No correctness bugs in the main change.

Two minor findings on the new inner window_to_ids lock in common.rs:

1. Poisoning cascade (line 185, correctness, plausible): Wrapping window_to_ids in its own RwLock introduces a new failure mode. If the index-build in exact_query's write-lock slow path (lines 262-269) ever panics, only the inner window_to_ids lock gets poisoned — the outer per-shard lock stays healthy. But insert() (line 185) and remove_windows() (line 320) call .get_mut().unwrap() on it with no graceful handling, so every future write to that epoch panics indefinitely instead of surfacing as a Result::Err, the way outer-lock poisoning was handled pre-PR.

2. Simplification (line 114, plausible): The manual double-checked-locking on RwLock<Option<HashMap<...>>> reimplements std::sync::OnceLock (stable since 1.70). OnceLock::get_or_init would replace the hand-rolled read-fast-path/write-slow-path/recheck logic (lines 251-277) with one call, and OnceLock::take() (needs &mut self, available at both invalidation sites) replaces the get_mut().unwrap() = None pattern at lines 185/320. It also sidesteps finding Initial public release of ASAPQuery #1: a panicking OnceLock initializer leaves the cell uninitialized rather than poisoned, so index-build failures would self-heal instead of permanently panicking future writes.

🤖 Generated with Claude Code

[zzylol]

lgtm