Add a batched exact-window query API to the store

[milindsrivastava1997]

Once #608 routes Sliding-window range queries through query_precomputed_output_exact (one call per output step instead of one wide scan), a range query over N output steps issues N sequential exact-window store calls where it previously issued one scan call. Even after #607 removes the write-lock cost, that's still N separate lock-acquire-and-lookup round trips instead of one.

Proposal

Add a batched variant, e.g. query_precomputed_output_exact_batch(metric, aggregation_id, windows: &[TimestampRange]) -> Result<Vec<TimestampedBucketsMap>, _> (exact shape TBD), that acquires the store shard lock once and resolves all requested exact windows against MutableEpoch/SealedEpoch in a single pass, instead of one lock cycle per window.

Scope

• asap-query-engine/src/stores/traits.rs — new trait method.
• asap-query-engine/src/stores/simple_map_store/{per_key,global}.rs — implementation.
• asap-query-engine/src/engines/simple_engine/mod.rs — range pipeline's per-step Sliding fetch (from Range queries over Sliding-window aggregations use overlap-scan fetch, not exact-window fetch #608) becomes one batched call up front instead of a call inside the per-step loop.

Sequencing

Pure perf follow-up, no correctness bug riding on it — #608's fix is correct with sequential exact calls today. Land after #607 and #608, whenever convenient.

Related: #581, #607, #608.

[milindsrivastava1997]

Confirming scope while planning #608: #608 will ship with N sequential exact calls in the per-step loop (no batching, no dedup across overlapping windows) — #609 will replace those N calls with one batched call later, as its own follow-up. #608 is not blocked on this landing first.

[milindsrivastava1997]

Scope suggestion: once this API exists, it should also become the implementation for scan_windows_via_exact (asap-query-engine/src/engines/simple_engine/mod.rs, added in #616), not just the #608 Sliding per-step fetch.

scan_windows_via_exact is the general non-exact-query fetch path (Tumbling range/instant queries, and non-DeltaSetAggregator keys queries) — it currently walks the aggregation's window grid and issues one query_precomputed_output_exact call per grid position in a loop, same shape as the N-sequential-calls problem this issue describes for #608's Sliding case, just triggered by a wide Tumbling range or a fine-grained keys query instead. A code review on #616 flagged this as a real perf concern (each grid position pays its own lock/lookup round trip) for e.g. a multi-day range query at 15s resolution.

Once the batched API lands, scan_windows_via_exact should build its full list of grid positions up front and hand them to one batched call instead of looping — same fix, same API, just a second call site. Doesn't cover the DeltaSetAggregator fallback case in scan_windows_via_exact (that one's [0, end_timestamp] range can be too wide to even enumerate, so it stays on the old scan regardless), but it should cover everything else that currently loops.

Worth adding to Scope above alongside the #608 range-pipeline call site.