perf: remove parser-stage guard to expand stats_query_range fast path

[szibis]

Summary

• Removes the queryUsesParserStages guard from shouldUseManualRangeMetricCompat for rate, bytes_rate, count_over_time, and bytes_over_time — queries with | json or | logfmt parser stages now use VL native stats_query_range when range == step (tumbling window)
• Drops the now-unused originalLogql 4th parameter from shouldUseManualRangeMetricCompat and updates both callers
• Sliding-window queries (range > step) remain on the slow manual path — !rangeEqualsStep gate is preserved for correct semantics

Why

The guard was conservative: VL stats_query_range natively handles inline filter pipelines including | unpack_json and | unpack_logfmt. Parser-stage queries were forced onto the raw-log-fetch + O(N) aggregation slow path even in tumbling-window configurations where VL native stats is semantically equivalent. This removed a significant bottleneck for common Grafana panels where step == $__interval == range.

Test Plan

• Unit tests: TestShouldUseManualRangeMetricCompat_ParserStageRate (9 cases) — parser-stage rate/count/bytes with tumbling window → fast path, sliding window → slow path preserved
• Integration tests: TestQueryRange_RateParserStageTumblingUsesStatsQueryRange and TestQueryRange_RateParserStageSlidingUsesSlowPath
• 1634 unit tests pass (go test ./internal/proxy/... -count=1)
• TestLogQL_Exhaustive_ErrorParity — 32 error parity cases pass
• TestLogQL_Exhaustive_QueryParity — 84 query parity cases pass
• TestPipeline_MetricQueries — parser-stage metric queries pass
• TestRangeMetricCompatibilityMatrix failures (rate, count_over_time, bytes_rate, bytes_over_time with step=60) are pre-existing and unrelated to this change (queries use no parser stages; code path is identical before/after)

[github-actions]

PR Quality Report

Compared against base branch main.

Coverage and tests

Signal	Base	PR	Delta
Test count	2494	2506	12
Coverage	87.1%	87.2%	+0.1% (improved)

Compatibility

Track	Base	PR	Delta
Loki API	100.0%	11/11 (100.0%)	0.0% (stable)
Logs Drilldown	100.0%	17/17 (100.0%)	0.0% (stable)
VictoriaLogs	100.0%	11/11 (100.0%)	0.0% (stable)

Performance smoke

Lower CPU cost (ns/op) is better. Lower benchmark memory cost (B/op, allocs/op) is better. Higher throughput is better. Lower load-test memory growth is better. Benchmark rows are medians from repeated samples.

Signal	Base	PR	Delta
QueryRange cache-hit CPU cost	1753.0 ns/op	1756.0 ns/op	+0.2% (stable)
QueryRange cache-hit memory	200.0 B/op	200.0 B/op	0.0% (stable)
QueryRange cache-hit allocations	7.0 allocs/op	7.0 allocs/op	0.0% (stable)
QueryRange cache-bypass CPU cost	2044.0 ns/op	1975.0 ns/op	-3.4% (stable)
QueryRange cache-bypass memory	286.0 B/op	286.0 B/op	0.0% (stable)
QueryRange cache-bypass allocations	7.0 allocs/op	7.0 allocs/op	0.0% (stable)
Labels cache-hit CPU cost	692.8 ns/op	682.0 ns/op	-1.6% (stable)
Labels cache-hit memory	48.0 B/op	48.0 B/op	0.0% (stable)
Labels cache-hit allocations	3.0 allocs/op	3.0 allocs/op	0.0% (stable)
Labels cache-bypass CPU cost	828.6 ns/op	806.0 ns/op	-2.7% (stable)
Labels cache-bypass memory	53.0 B/op	53.0 B/op	0.0% (stable)
Labels cache-bypass allocations	3.0 allocs/op	3.0 allocs/op	0.0% (stable)

State

• Coverage, compatibility, and sampled performance are reported here from the same PR workflow.
• This is a delta report, not a release gate by itself. Required checks still decide merge safety.
• Performance is a smoke comparison, not a full benchmark lab run.
• Delta states use the same noise guards as the quality gate (percent + absolute + low-baseline checks), so report labels match merge-gate behavior.