feat: execute planned ClickHouse SQL summaries

[zzylol]

Why

ClickHouse requests could proxy and execute hand-built summary DAGs, but planner-produced SQL with relational roots never reached recursive summary selection. The observability SQL corpus also used ClickHouse-specific exact SQL that the canonical frontend could not parse, and ratio queries had no read-time relational join over two selected summaries.

What

• Separates the exact ClickHouse request/fallback template from an explicitly equivalent planning_sql owned by the ClickHouse workload sidecar.
• Uses ASAPPlanner workload materialization for SQL roots so Project, Filter, Sort, and Limit preserve selected inner summaries.
• Binds bounded SQL table scans and temporal asap_rate/asap_increase plans to existing SDS materializations without changing the PromQL binder or SDS descriptor meanings.
• Pins the reviewed ASAPPlanner SQL temporal and read-time RelationalJoin work from PRs test(monitor): fix monitor_grpc integration-test compile (rate field from #368) #369 and test(monitor): live multi-edge coupling over gRPC (differentiated sample_p) #370.
• Compiles two selected SQL summary sub-DAGs into a read-time equi join, validates coverage independently for every leaf, and reuses Project arithmetic and typed ClickHouse result encoding.
• Keeps unsupported last semantics fail-closed and documents why existing MinMax/Increase state cannot be reused safely.

How

The control plane parses only planning_sql and publishes the original exact SQL as the strict runtime identity and fallback template. The data plane looks up that exact template without reparsing ClickHouse-only tuple/map/lambda syntax. RelationalJoin recursively executes its two reachable summary DAGs, checks each leaf against its own pane window and origin, joins rows on the reviewed cross-input equality predicate, and applies the existing relational projection.

Before this PR

SELECT labels, max(value) ... ORDER BY labels stopped at root-only candidate selection, while expanded rate and ratio SQL stopped in the SQL frontend. No control-plane artifact had been proven through publication, backfill, SummaryStore, and the ClickHouse HTTP warm path.

After this PR

A bounded grouped max query compiles, publishes, backfills from a real ClickHouse server, and returns a typed warm result equal to native ClickHouse. Planner-friendly rate/increase SQL compiles into existing exact counter summaries with strict series-identity proof. A two-rate ratio compiles into two SDS bindings plus RelationalJoin and returns 0.2 from real SummaryStore panes; a missing pane on either input routes to exact fallback.

Verification

• cargo test -p control_plane clickhouse --lib — 6/6 passed.
• cargo test -p data_plane asap_clickhouse_query_engine --lib — 15/15 passed.
• cargo test -p data_plane --test clickhouse_ratio_store_e2e -- --nocapture — passed, including unequal pane windows and one-side coverage failure.
• CLICKHOUSE_URL=http://127.0.0.1:18123 CLICKHOUSE_USER=bench CLICKHOUSE_PASSWORD=bench cargo test -p data_plane --test clickhouse_q05_process_e2e -- --nocapture — passed against real ClickHouse; asserted x-asap-execution=warm and differential equality.
• cargo check --all-targets -q — passed.
• cargo fmt -p control_plane -p data_plane -- --check and git diff --check — passed.
• Independent review: PASS after per-leaf coverage and isolated process-state blockers were fixed.

Limitations

Planning SQL functions are a control-plane contract; the exact SQL remains the ClickHouse-executable fallback. asap_last, temporal grids/subqueries, and histogram quantile remain typed fallback until they can be implemented without changing existing shared SDS semantics. This PR depends on ASAPPlanner PRs #369 and #370.

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:

[zzylol]

Closing as superseded by the unified ClickHouse path merged through #589 and its prerequisite stack. This branch retains the older independent plan-catalog/sidecar architecture and should not be merged into current main.