refactor(legacy_expr): step γ4 — TopK bridge (heavy-hitter vs Sort+Limit split)

[zzylol]

Summary

Per design.md §3 + §6 "What was removed" row 1: TopK collapses two distinct concepts — heavy-hitter intent (sketch primitive) + generic Sort + Limit. The bridge splits these explicitly.

Follows γ1's strategy (c): keep legacy QueryExpr::TopK variant in place; provide a canonical-view helper consumers call on demand. No construction-site rewrites.

New: topk_bridge.rs (333 lines, 7 tests)

pub enum BridgedTopK {
    HeavyHitter { k: usize, by: Vec<ColumnId>, intent: AggIntent },
    SortLimit   { k: usize, by: Vec<ColumnId> },
}
pub fn bridge_topk(k: usize, by: &[ColumnRef], schema: &Schema)
    -> Result<BridgedTopK, BridgeError>;

HeavyHitter.intent carries AggIntent::TopK { k, accuracy: Epsilon(0.05) } — L4 BindCmsTopK rules read it directly.

Classification: defaults to HeavyHitter

Only L1 form lowering to legacy TopK in this tree is PromQL topk(…) (both heavy-hitter intent). SQL ORDER BY name LIMIT 10 already goes through legacy::Sort + Limit. γ7 refines via context flag if a SQL distinction becomes needed.

Demo wire

physical/allocator.rs::alloc_node TopK arm — wraps Vec<String> → Vec<ColumnRef::Named>, calls bridge, folds canonical intent kind + resolved col count into NodeAnnotation.rationale.

Build + test

• cargo build --release -p controller clean
• cargo test -p controller --lib — 695 passed (was 688; +7 new tests)

Diff: 3 files, +374 / -1

🤖 Generated with Claude Code