SQL front end never populates Aggregate.having from a real HAVING clause #201

Summary

QueryExpr::Aggregate.having exists specifically so the L3→L4 binding pass can see a post-aggregation predicate directly on the Aggregate node (crates/asap-aware-mapping/src/bind.rs's single-measure/no-having bindable check treats any having as "stays logical," same reason a multi-measure aggs does).

The SQL front end never sets it, though — both Aggregate construction sites in crates/frontend-sql/src/sql/mod.rs hardcode having: None:

Ok(L2::Aggregate {
    keys,
    without: false,
    aggs,
    having: None,   // <- always None
    input,
})

So for e.g.

SELECT srcip, COUNT(*) AS cnt FROM packets GROUP BY srcip HAVING COUNT(*) > 10

the parser doesn't lower HAVING COUNT(*) > 10 into Aggregate.having at all — it (presumably) drops the predicate today, or the query fails elsewhere. having is otherwise fully plumbed through — crates/l2/src/lower.rs, crates/l2/src/column_resolution.rs, and crates/asap-aware-mapping/src/bind.rs all handle a populated having, and it's exercised by hand-built L2/L3 trees in tests (crates/l2/src/lower.rs:953 having_resolves_against_aggregate_output_schema, crates/asap-aware-mapping/src/bind.rs:693 having_and_multi_intent_stay_logical) — just never by parsed SQL.

Ask

Wire the SQL front end's HAVING clause into Aggregate.having (or, if a derived-table WHERE over an aggregate output — SELECT * FROM (SELECT srcip, COUNT(*) cnt FROM packets GROUP BY srcip) t WHERE cnt > 10 — is meant to stay a separate Filter node rather than fold into having, confirm that's the intended split and document it). Whichever shape is intended, right now real HAVING SQL doesn't reach either shape correctly.

Surfaced while documenting Aggregate in docs/pre-asap-ir.md (#185, #199).