feat: compile PromQL comparisons and set operators

[zzylol]

Stacked on #490.

Rebuilt into the linear stack on main. New integrate: commit(s) fold in integration-branch resolutions this PR needs on top of the earlier stack: "widen shared series identity to every PromQL binary operator". Conflict resolutions are recorded in the messages of: "feat(physical): compile PromQL comparisons, set operators, and group modifiers".

Why

compile rejected PromQL comparisons, set operators, group_left/group_right, and non-literal scalar operands, so the backend still had to lower them itself. The frontend also dropped bool, so a > bool 1 lowered the same way as the filter a > 1.

What

• IR: a new variant, BinaryOpKind::CompareBool(CompareOpKind), sits beside the filtering Compare. The PromQL frontend emits it for bool. I used a variant rather than a return_bool flag for two reasons: only comparisons accept bool, and the variant reaches both QueryExpr::BinaryOp and the post-ASAP Binary payload without changing any construction sites.
• Operator::series_binary now implements Prometheus' VectorBinop, VectorAnd/Or/Unless, and vector-scalar semantics:
  • arithmetic, comparison filters, and bool comparisons
  • vector, literal, scalar(), and scalar-expression operands
  • one-to-one matching, and group_left/group_right with included labels
  • and/or/unless with on/ignoring
  • __name__ and duplicate handling as in Prometheus
• Where it is used: Fallback subtrees and query-time Binary nodes. This replaces the literal projection, the relabel+binary chain, and the grouped relational join.
• Range functions: in the Fallback, every range function except last_over_time now drops __name__, and series whose label sets then become equal are an error.
• Label-map vector_binary: it now treats CompareBool as its bool mode.

Before this PR

a > bool 1                    -> lowered as the filter a > 1
a > 5, a and b, a or vector(0) -> compile error
a * on(job) group_left(team) info, a * scalar(b), sum by (job)(a) * 2 -> compile error
rate({job="x"}[1m]) over series differing only in __name__ -> two series

After this PR

The results below were checked against hand-computed Prometheus results.

• a = {job=x} 10, {job=y} 20, {job=w} 0, {job=n} NaN:
  • a > 5 gives a{job=x} 10, a{job=y} 20.
  • a > bool 5 gives {job=n} 0, {job=w} 0, {job=x} 1, {job=y} 1.
• a * on(job) group_left(team) info gives {inst=1,job=x,team=t1} 20, ….
• sum(a) or vector(0) gives {} 0 when a is empty.
• rate(...) over series whose label sets are equal without the name fails with "vector cannot contain metrics with the same labelset".

Remaining

• Per-series Binary filters and set operators fail closed. Stored readouts keep __name__ where the range function drops it.
• Labels with no column fail closed. A group_left label, or right-side labels from or/group_right, cannot be added to aggregated label-column rows, because the left logical schema has no column for them. Example: sum by (job)(a) * on(job) group_left(team) info.
• time() operands are not covered.
• NaN and Inf literals do not survive the program's JSON round trip.
• Inner functions in a subquery have no per-step check for equal label sets.
• fill modifiers are still ignored by the frontend. Rejecting them drops 27 corpus queries below the lowering floor.
• The other shapes are listed in docs/develop_docs/physical-compile-coverage.md.

Validation

• cargo fmt --all --check, cargo clippy --workspace --all-targets -- -D warnings, and cargo test --workspace --no-fail-fast all pass.

• The new Fallback tests fail on the base branch's sources and pass here. The new IR tests do not compile on the base branch.

• An independent reviewer agent found three bugs, each now covered by a regression test:

  • scalar-valued expression operands such as a + -scalar(b)
  • bool in vector_binary kept __name__
  • the inner subquery function kept __name__

  The reviewer also found that or vector(0) was rejected; that is fixed too.

🤖 Generated with Claude Code

[zzylol]

Included in the squash merge of #493 into main (deb3904).