feat(core): introduce QueryExpr::TimeRange for range-vector semantics

[milindsrivastava1997]

Summary

• Adds QueryExpr::TimeRange { range: Duration, child } as a dedicated L3 IR node for all range-vector functions (rate, increase, *_over_time). This replaces the incorrect use of Window { Tumbling } which is semantically a streaming query-repetition window, not a temporal lookback range.
• AggIntent::Rate and AggIntent::Increase are now unit variants — the range duration is carried by the enclosing TimeRange node, keeping the intent vocabulary range-agnostic.
• topk(k, count_over_time(...)) now preserves the Count intent in L3 (outer Aggregate { [TopK] } wraps inner Aggregate { [Count], child=TimeRange }). L4 may fuse these into a single-pass SpaceSaving/CMS-with-heap sketch, but that is a cost-model decision, not an L3 concern.
• Adds crates/e2e shared test fixture crate; updates all tests in promql_lowering.rs and promql_conformance.rs to assert the new IR structure.

Test plan

• cargo test — all tests pass (promql_lowering, promql_conformance, promql_corpus, SQL lowering, core schema derivation)
• cargo clippy --all-targets — no warnings
• Corpus coverage: ≥520 testdata queries lower to Ok (threshold unchanged)
• topk_over_count_is_heavy_hitter_topk asserts both Count and TopK intents are visible in L3
• rate_has_time_range_child_not_window and increase_maps_to_increase_intent confirm TimeRange wraps the scan

🤖 Generated with Claude Code

[milindsrivastava1997]

@zzylol I added a TImeRange node to represent a filter over a time column. This is different from TimeWindow i.e. is used for repeating query workloads and is either a tumbling or sliding or session window.