[timeseries] Add outer range-query vector-selector preload fast path

[apurvam]

Issue #348 reduces repeated warm-query evaluator work via query-scoped caches and shared canonical labels, but it intentionally does not add a new evaluator fast path.

Range queries are still evaluated as repeated instant evaluations across outer steps. After #348 lands, we may still be doing too much repeated selector work per step even when cache hit rates are already high.

This issue should add a fast path for outer query_range evaluation over eligible VectorSelector leaves:

• preload the selector results once for the outer step grid
• build per-series per-step latest-sample tables
• let later outer steps reuse those tables instead of rerunning selector evaluation and sample selection each time

Scope constraints:

• apply only to outer query_range context
• start with direct or simple VectorSelector leaves
• keep subqueries and matrix selectors on the existing path initially
• preserve the current pipeline/concurrency model instead of adding a fully separate read path

Expected gains:

• potentially large warm-query reductions on step-heavy range queries with repeated vector-selector evaluation
• the gains should scale with step count and selector reuse

When the gains are realized:

• after Issue [timeseries] Reduce repeated work in the evaluator #348 has landed
• when post-348 stats show:
  • high selector and sample cache hit rates
  • but warm range queries still spend substantial CPU reevaluating the same vector selectors across many outer steps
• most likely on:
  • long query_range requests with many steps
  • pure vector selectors
  • simple aggregations or binary expressions over vector-selector leaves
• not expected to help much on:
  • matrix-selector-heavy queries such as rate(metric[5m])
  • cold queries dominated by I/O misses
  • complex subquery contexts without additional gating

Suggested acceptance criteria:

• post-348 profiles confirm repeated outer-step selector evaluation is still a top warm-query cost
• preload is correctly gated to the outer range-query context
• correctness is preserved for offset / @
• benchmark notes show a clear warm-query win on the targeted step-heavy scenarios