Unify PromQL instant and range query fetch/merge paths

[milindsrivastava1997]

PromQL instant queries and range queries use two independently implemented fetch/merge designs for the same underlying job, not one design expressed twice.

• Instant: one targeted fetch per values_query (exact-window if Sliding, range if Tumbling), merged once via merge_precomputed_outputs (fold over merge_with, with a do_merge short-circuit when only one bucket is in range).
• Range: one big contiguous fetch over the whole extended range, then a fresh WindowMerger/NaiveMerger built and fully re-merged from scratch per output step, per key. The trait's incremental slide() (add/remove) is never used.
• Key resolution is duplicated too: collect_all_results/collect_results_separate_keys/collect_results_same_aggregation (instant) vs the inline is_dual_population/get_keys()/fallback logic in execute_range_query_pipeline (range) independently reimplement "which output keys does this group serve." Already caused 3 separate bugs (fix(query-engine): merge all sliding-window buckets per key instead of taking first #570, fix(query-engine): range queries expand keys_query and merge same-timestamp buckets #582, fix(query-engine): expand self-keyed accumulators in range queries #587) from the two paths drifting apart. Should collapse to one shared resolver both paths call.

Binary-expr instant and range queries each just run the corresponding plain-query pipeline once per arm and combine client-side, so this fork is duplicated across all four PromQL query paths, not just the two plain ones.

[milindsrivastava1997]

is_exact_query still hardcoded false for range queries — #580 not fully fixed

finish_range_context (asap-query-engine/src/engines/simple_engine/promql.rs:585) still unconditionally sets extended_store_plan.values_query.is_exact_query = false, regardless of the aggregation's actual WindowType. This is exactly problem #2 named in #580, which PR #582 closed — but #582's changes (keys_query expansion, same-timestamp bucket collision) never touched this line. The bug is still live on main.

Effect: a PromQL range query over a Sliding-window aggregation gets routed to the overlap-scan fetch (query_precomputed_output) instead of the exact-window fetch (query_precomputed_output_exact), and is then merged downstream as if it were Tumbling (window_type = if is_exact_query {Sliding} else {Tumbling}, simple_engine/mod.rs:545) — wrong values, silently, no error.

Instant queries don't have this bug: create_store_query_plan correctly derives is_exact_query = window_type == WindowType::Sliding (simple_engine/mod.rs:414). Only the range path hardcodes it away.

Proposal to consider as part of this unification: instead of re-deriving is_exact_query correctly in the range path (mirroring case 1), consider removing is_exact_query as a threaded bool field entirely — infer which store lookup to call (query_precomputed_output vs _exact) directly from WindowType at the fetch call site, in both the instant and range paths. Would remove one more place the two paths can independently drift out of sync, on top of the fetch/merge unification this issue already covers.

[milindsrivastava1997]

Staged unification plan:

1. Align call order between the two pipelines (fetch values → fetch+merge keys → merge values → ...) — zero behavior change. Also rename range's window_mode (sliding/hopping step-iteration label) so it stops colliding in name with instant's window_type (Sliding/Tumbling store-fetch mode).
2. Extract range's inline logic into named helpers mirroring instant's — groups resolution → shared with collect_results_separate_keys/collect_results_same_aggregation; bucket-map-build + window-walk → its own helper. Zero behavior change; makes the two pipelines diff-able side by side.
3. Unify the merge engine — merge_accumulators (KLL/CMS batch-merge fast path) vs NaiveMerger (always sequential, slide() unused). The one real behavior fork; needs equivalence tests before either call site changes, own commit.
4. Collapse instant into range — execute_query_pipeline becomes execute_range_query_pipeline with a single step. The actual unification; 1-3 just make it reviewable.

Must resolve before/during step 4, not after: Sliding forced-false bug in range fetch, top-k has no range semantics yet, partial-data/error tolerance differs between the two, SQL/Elastic call execute_query_pipeline directly so their call sites are in scope too.