Execute scalar operator references in Project/Filter expressions of the physical DAG #668

Problem

After #542, the Planner plans and costs PromQL vector op scalar(v) forms such as rate(a[5m]) / scalar(rate(b[5m])) and rate(a[5m]) > scalar(rate(b[5m])). In the exported PhysicalASAPDAG, a Project or Filter expression then reads another operator's output through a ScalarExpr operator reference, with a ScalarRef edge to that node.

The physical operator compiler cannot run this yet. local_scalar in crates/asap-physical-operators/src/physical_planner/mod.rs (unified_physical_planner/mod.rs before #665) rejects any expression with operator references:

fn local_scalar(expr: &ScalarExpr<PhysicalASAPNodeId>) -> Result<ScalarExpr, Error> {
    if !expr.operator_refs().is_empty() {
        return Err(invalid("scalar plan reads require explicit execution bindings"));
    }
    ...
}

So these queries plan successfully but fail to compile on the execution side.

Scope

By design the Planner has no execution fallback: executing the plan is the deployment runtime's job. This issue is about the execution side (asap-physical-operators and the ASAPQuery backend), not about planning:

• Bind each referenced node's output as a scalar input (the scalar of a one-element instant vector, NaN otherwise, as in PromQL scalar()) and evaluate the Project/Filter expression against it.
• The same reference may appear more than once in one expression; it should be evaluated once.
• Standalone scalar queries (scalar_roots) need the same binding.

Done when

rate(a[5m]) / scalar(rate(b[5m])), rate(a[5m]) > scalar(rate(b[5m])) and a standalone scalar(...) query compile and execute from the exported PhysicalASAPDAG, with results matching Prometheus.

Found in the second review round of #542.