feat(ir): shared L3 canonicalization pass for heavy-hitter topk (#34)

[zzylol]

Closes #34. Fixes #20 (SQL alias gate miss) and #25 (SQL/PromQL heavy-hitter tree divergence) as a side effect.

Problem

Semantically identical "top-k by count" queries produced different L3 depending on source language, and each front end had its own heavy-hitter recognition gate with subtly different logic:

• SQL ORDER BY cnt DESC (aliased) silently fell through to Sort+Limit while ORDER BY COUNT(*) DESC hit the gate (SQL heavy-hitter gate misses count-ranked topk when COUNT is aliased #20).
• SQL's heavy-hitter was Aggregate([TopK]) { Scan } (count implicit); PromQL's was Aggregate([TopK]) { Aggregate([Count]) { … } } (count explicit) (L3 IR structural inconsistency: SQL and PromQL heavy-hitter topk produce different tree shapes #25).

Fix: one shared pass

asap_l2::canonicalize — a bottom-up L3 rewrite run at the end of the shared convert_root, so both front ends (and any future language) get it for free. It promotes a count-ranked

Limit { Sort DESC-by-count { [Project] Aggregate([Count], by: G) } }

into the canonical

Aggregate { by: <sort partition>, aggs: [TopK{k}],
            child: Aggregate { by: G, aggs: [Count], … } }

The match is positional — the DESC key must resolve (through an optional passthrough projection) to the Count's output column — so it doesn't care whether the count was aliased. That kills #20 without any SQL-plan-specific alias handling.

The SQL front-end gate is removed (heavy_hitter_topk / lower_as_topk + helpers): SQL now emits a plain Sort+Limit and lets canonicalize do the promotion — the same path PromQL's generic topk takes. PromQL's topk(k, count_over_time(…)) gate still emits the canonical shape directly (canonicalize is idempotent on it).

Result: SQL and PromQL heavy-hitters are now structurally identical above the leaf — TopK over an explicit Count — differing only in what they count (SQL rows vs. windowed samples), which is the genuinely intentional part of #25. The outer TopK.by is the ranking partition ([] for a global ORDER BY … LIMIT k); the grouping lives on the inner Count.

Tests

• asap-l2 unit tests for the pass in isolation: promotion (with and without a passthrough projection), idempotency, and negatives — ascending sort, OFFSET, ranking a group key, non-Count aggregate.
• crates/lower/tests/cross_language.rs — the executable spec L3 IR standardization: cross-language correctness and canonicalization #34 asked for: SQL S2 and PromQL P1 reach the same canonical shape; SQL aliased ≡ inline (SQL heavy-hitter gate misses count-ranked topk when COUNT is aliased #20 regression); non-count and OFFSET stay generic in both languages.
• Updated count_ranked_topk_is_heavy_hitter to the canonical two-level form (outer global TopK, inner Count by service).

Verified via the topk_ir example: S1≡S2 now, S3 (OFFSET) / S4 (SUM) / S5 (AVG) stay Sort+Limit, P1/P10 unchanged.

Full workspace suite green; clippy clean.

Not in scope

min_of/max_of etc. are unrelated. Partitioned SQL topk (S8/S9, #24) now lowers on its own (derived-table support landed since #24 was filed) and is untouched here.