feat(sql): lower temporal and histogram planning bridges

[zzylol]

Why

Equivalent ClickHouse planning SQL for PromQL subqueries and classic histograms could not express the temporal evaluation grid or bucket interpolation already present in the canonical query DAG. Those queries therefore stopped at the SQL frontend even though the shared planner and runtime already understand the canonical operations.

What

Adds two planning-only SQL relation markers:

• asap_promql_subquery(range_ms, resolution_ms) lowers to the existing QueryExpr::PromqlSubquery.
• asap_histogram_quantile(q) lowers to the existing AggIntent::HistogramQuantile.

How

The SQL frontend registers type-only UDF stubs so DataFusion accepts the marker syntax. Projection lowering consumes each marker and constructs the existing canonical node. The temporal marker must be aliased to an existing child value column, and its surrounding projection is retained. Histogram markers must be the only projected expression. Literal, arity, range, and ambiguity checks fail closed.

Before this PR

SQL could express ordinary and temporal aggregates but could not state PromQL subquery grids or classic cumulative-bucket interpolation in an equivalent planning rewrite.

After this PR

Control planes can supply explicit equivalent planning SQL for these two operations while exact ClickHouse SQL remains the request and fallback identity. No canonical IR, physical DAG, or SDS type changes.

Evidence

The new lowering tests assert the emitted canonical variants and duration/quantile parameters. Invalid marker shapes are rejected.

Verification

• Unit tests: cargo test -p asap-frontend-sql — 90 tests passed across unit and integration suites.
• End-to-end tests: not applicable; this PR is confined to frontend lowering and the backend integration is tested separately.
• Other checks: cargo fmt --all -- --check; git diff --check.

Architectural decisions

The bridge reuses existing canonical types instead of adding SQL-specific DAG or SDS variants. The marker is planning-only and is always consumed by lowering, so it cannot reach an executor as an opaque scalar function.

Limitations and follow-up

These markers assert equivalence supplied by the workload author. They are deliberately unavailable as general ClickHouse execution functions. Backend publication must still validate physical/runtime capability and coverage before serving warm results.

Human review — do not complete with an agent

• The MVP boundary is correct.
• New conceptual layers or public interfaces are necessary.
• The before/after description matches the intended product behavior.
• Human reviewer:
• Decision and rationale: