Support range-query lookback wider than a Sliding aggregation's window_size_ms #623

Found while scoping #608. Today, a range query's lookback for a Sliding aggregation is always the aggregation's configured window_size_ms, regardless of what duration the PromQL selector actually says.

Current behavior

create_store_query_plan (mod.rs:432-436, instant path) computes the window as [end - window_size_ms, end] using the aggregation's configured window_size_ms — not whatever duration was parsed from the selector. finish_range_context's lookback (widen_query_window, promql.rs) derives from that same instant window's width, so it's window_size_ms too, transitively. The selector's own stated duration (the [Ns] text) isn't read anywhere in promql.rs's query-timing logic.

Concretely: with window_size_ms=5000, slide_interval_ms=1000, sum_over_time(cpu_load[10s]) and sum_over_time(cpu_load[5s]) produce identical results against this aggregation — the 10s is silently discarded in favor of the aggregation's real 5s window.

This was confirmed not to be a problem for #608's fix specifically (single-bucket lookup is correct and complete given this constraint), but it's a real, separate correctness/usability gap: a user writing [10s] reasonably expects 10 seconds of lookback, not silent substitution.

What removing the restriction would require

Given the store only ever holds one pre-merged, window_size_ms-wide bucket per grid position (worker.rs::merge_panes_for_window fully merges before storing — confirmed while investigating #608, no raw sub-window panes are ever stored), honoring a lookback wider than window_size_ms means merging multiple non-overlapping buckets, spaced window_size_ms apart (not the slide grid) -- e.g. for window_size_ms=5000 and a desired 10s lookback, sum the bucket ending at t with the bucket ending at t - 5000.

This is a genuinely different composition than both single_window (#608, one bucket) and scan_window (Tumbling, sum every grid position) — a third mode: sum every window_size_ms-th bucket within the requested lookback, skipping the ones in between (which overlap and would double-count).

Options worth considering

1. Implement the above (support arbitrary lookback via non-overlapping multi-bucket merge).
2. Or, if that's not wanted: validate the selector duration against the aggregation's configured window_size_ms and error/warn on mismatch, instead of silently substituting -- cheaper, but doesn't add the capability, just makes today's limitation explicit.

Scope

• asap-query-engine/src/engines/simple_engine/promql.rs -- create_store_query_plan, finish_range_context.
• Whatever new per-step composition mode this needs in execute_range_query_pipeline / single_window (mod.rs), alongside the existing Sliding (Range queries over Sliding-window aggregations use overlap-scan fetch, not exact-window fetch #608) and Tumbling paths.

Related: #557, #608.