post-asap: GroupingStrategy axis - PerSubpopulationInstance vs SharedMultiSubpopulation (Hydra) summary types

[zzylol]

Part of #33.

What

A new orthogonal axis on Implementation/SummaryFamilyType, alongside SketchKind/SamplingKind/WaveletKind/StatModelKind: how a grouped aggregate's summary state is physically instantiated across its by subpopulations.

/// Orthogonal to which summary family/kind is chosen — how many physical
/// instances of it exist across a grouped aggregate's subpopulations.
#[derive(Debug, Clone, PartialEq)]
pub enum GroupingStrategy {
    /// Today's only (implicit) behavior: one summary instance per distinct
    /// `by` key.
    PerSubpopulationInstance,
    /// One shared structure serving every subpopulation (Hydra and its
    /// per-family variants — HydraKLL, HydraCMS, HydraHLL, HydraUnivMon,
    /// per the existing `hydra_*` wrappers in this org's sketch-bench).
    SharedMultiSubpopulation { kind: HydraKind, params: HydraParams },
}

(Named SharedMultiSubpopulation, not SharedMultiTenant — this is sharing across the query's own subpopulations/group-by keys, not multi-tenant in the deployment-isolation sense.)

HydraKind/HydraParams mirror the existing per-family (Kind, Params) pattern (SketchKind/SketchParams, etc. in asap_types::post_asap).

Where it plugs in

• Implementation::Sketch/Sample/Wavelet each grow a grouping: GroupingStrategy field (a breaking change to those variants — scoped as its own issue for exactly that reason, per the discussion on Add logic to detect which optimizations are applicable to a query workload #33).
• Exposed as another ReplacementStrategy (see that sub-issue): candidates() only produces a SharedMultiSubpopulation alternative when by is non-empty (empty by has no subpopulation axis at all) and a Hydra variant exists for the chosen family.
• Legality, not cost: whether Hydra is worth it for a given estimated subpopulation cardinality is a cost-model question (deployment-owned, out of scope here); whether it's valid at all (non-empty by, family has a Hydra variant) is what this issue's strategy must gate correctly, same split boundary::implementation_for already draws between "can this be built" and "should it be."
• Must call the roll-up sub-issue's merge-legality predicate before offering a SharedMultiSubpopulation candidate as either side of a roll-up substitution, rather than assuming every combination composes.

[zzylol]

Implemented in the PR stacked on #251/#259. Placement ended up different from this issue's original sketch, documented here so the tracking issue matches reality (same spirit as #251's actual Replacement shape diverging slightly from its own issue text).

What shipped, and where

• HydraKind/HydraParams/GroupingStrategy land in asap_types::post_asap (crates/types/src/post_asap/sketch.rs), exactly as sketched — one starting HydraKind::HydraKll variant, HydraParams::HydraKll { k, shared_buckets } (per-subpopulation accuracy knob + shared-structure sizing knob), GroupingStrategy::{PerSubpopulationInstance, SharedMultiSubpopulation { kind, params }}, defaulting to PerSubpopulationInstance.
• GroupingStrategy itself is carried on SummaryExpr::SummaryAgg (crates/types/src/post_asap/expr.rs), not on Implementation/SummaryFamilyType.

Why the change

boundary::implementation_for/implementation_for_with — the functions that actually produce an Implementation — take only &AggIntent. They never see a Reduction/by at all, because the sketch-vs-exact boundary decision is genuinely independent of grouping. Adding a GroupingStrategy field to Implementation::Sketch/Sample/Wavelet (and the mirrored SummaryFamilyType variants) would have forced every one of their many call sites and match arms across boundary.rs, bind.rs, cost_model.rs, and replacement.rs (plus every test in each) to either invent a Reduction they don't have or thread one through for a decision that never consults it — reintroducing, one layer up, the exact false-orthogonality problem this axis exists to fix.

SummaryExpr::SummaryAgg already carries the one field this axis's legality actually depends on: reduction (the by keys), right next to family (the "which kind" axis). Placing GroupingStrategy there instead means:

• exactly one producer to update — bind::bind_summary_agg — instead of every Implementation/SummaryFamilyType construction/match site in four modules;
• the non-empty-by legality check is a local read of a field already in scope, not a value threaded in from three layers up;
• Implementation/SummaryFamilyType's shapes are byte-for-byte unchanged, so no existing match site (in this crate or any downstream deployment) needed touching at all.

Legality rules (as scoped — cost sizing stays out of scope)

• SharedMultiSubpopulation is only offered when reduction has a genuine subpopulation concept (non-empty by, or a without(...) exclusion grouping) — never for a global reduction or a per-entity (Reduction::PerEntity) shape. See asap_aware_mapping::grouping::has_subpopulations.
• Only offered when the candidate SketchKind has a modeled Hydra variant (asap_types::post_asap::hydra_kind_for — KLL only, today).
• Whether it's worth it for an estimated subpopulation cardinality stays a cost-model concern, out of scope here, same split boundary::implementation_for already draws.
• Exposed as a new ReplacementStrategy, asap_aware_mapping::grouping::HydraGroupingStrategy: for a target SketchFamilyStrategy already has an opinion on, it offers an additional SharedMultiSubpopulation candidate alongside (not instead of) whatever SketchFamilyStrategy itself enumerates.
• Cross-axis roll-up legality (asap-aware-mapping: group-by-lattice roll-up reuse (fine-to-coarse) as a ReplacementStrategy #254): feat/rollup-lattice-254 had no commits beyond the shared #251 base at the time this was written (no standalone roll-up legality predicate existed yet to call), so a // TODO(#254): marker sits at the exact point in HydraGroupingStrategy::build_candidate where that predicate needs to be consulted once asap-aware-mapping: group-by-lattice roll-up reuse (fine-to-coarse) as a ReplacementStrategy #254 lands, with a one-sentence explanation of why.

cargo build --workspace --all-targets, cargo test --workspace, cargo fmt --all -- --check, and cargo clippy --workspace --all-targets --all-features -- -D warnings all pass clean.