fix(sketch): SummaryAgg carries L3's Reduction directly, resolving the empty-by ambiguity

[zzylol]

Summary

Fixes #163.

Reworked on top of #165/#166 (was previously a standalone SummaryGrouping type at L4 — see prior review discussion below). Now that Reduction::{Reduce(GroupKeys), PerEntity} exists at L3 and asap-plan::bind already decides it once at L3→L4 binding, this PR just stops flattening that decision back into an ambiguous bare Vec<ColumnId> on the way into SummaryAgg — SummaryAgg carries Reduction directly, verbatim, rather than introducing a parallel L4 type.

SummaryExecutor::find_candidates's by: &[ColumnId] becomes reduction: &Reduction, so every implementer (including ASAPQuery-backend's data_plane, the consumer that hit this) must handle both cases explicitly instead of guessing:

• A bare per-series range function with no grouping syntax at all (quantile_over_time(0.99, m[10s])) — no grouping concept, must never merge across entities.
• An aggregation operator explicitly invoked with no by(...) (count(hll_metric)) — a genuine full reduction, must merge everything into one group.

Both used to collapse to the same by: [], with nothing in the trait able to tell them apart (see the issue for a concrete two-disjoint-HLL-sids repro).

Changes

• asap-sketch: SummaryExpr::SummaryAgg.by: Vec<ColumnId> → reduction: Reduction (the same L3 type, re-exported nowhere new — callers already import it from asap-ir). SummaryExecutor::find_candidates takes reduction: &Reduction instead of a bare by slice; doc comments spell out the two distinct contracts.
• asap-plan: bind_summary_agg passes reduction.clone() straight onto SummaryAgg instead of flattening it — no new logic, since Design proposal: separate "what kind of computation" from "which dimensions to group by" in the intent algebra (dbt-style measure/dimension split) #165 already computes everything needed.
• No new type introduced at L4 — Reduction is reused as-is, avoiding a redundant parallel enum.

Test plan

• Two asap-plan binding tests proving the L3 Reduction survives onto the L4 SummaryAgg node unchanged for both ambiguous cases — the classification logic itself is already covered by Design proposal: separate "what kind of computation" from "which dimensions to group by" in the intent algebra (dbt-style measure/dimension split) #165's much larger test suite (100+ conformance tests), so these are narrowly scoped to the L3→L4 passthrough.
• New asap-sketch wiring test proving execute() passes reduction through to find_candidates unmodified.
• Existing asap-plan/asap-sketch/e2e tests and assertions updated to the new shape.
• cargo build --workspace / cargo test --workspace — clean.
• cargo clippy --workspace --all-targets --all-features -- -D warnings — clean.
• cargo fmt --all --check — clean.

🤖 Generated with Claude Code

[zzylol]

I have a worry about whether this fits for SQL path. Currently it's solving a PromQL case.