PromQL: min_of / max_of scalar reducers unsupported #89

Summary

min_of(s1, s2, …) and max_of(s1, s2, …) parse but are rejected (UnsupportedFunction). Split out of #51, which landed the extra *_over_time reducers and the sort family.

Per the parser signature they are n-ary scalar reducers: vec![Scalar, Scalar] variadic → Scalar. min_of(1, 2, 3) → the scalar 1.

Corpus impact

~14 rejections.

Why deferred

In the corpus these are almost always nested with the step() / range() scalar helpers inside range-selector / offset / @ positions — all of which are themselves unsupported:

count_over_time(metric1_total[min_of(step()+1, 1h)])
metric1_total offset min_of(step(), 1s)

So min_of/max_of can't be exercised end-to-end until step()/range() and dynamic range/offset expressions land. They also need a scalar-reduction representation: the current QueryExpr::Scalar(f64) leaf only holds a constant, so a non-constant min_of(step(), …) has nowhere to go. A constant-only fold (min_of(1,2) → Scalar(1)) is possible but wouldn't help the real corpus cases.

Design questions: a scalar n-ary min/max expression node (or fold at num_expr for the constant case); dependency on step()/range() scalar helpers; dynamic range/offset support.

Pin

min_of_max_of_are_rejected__GAP in crates/frontend-promql/tests/promql_conformance.rs (§U).