refactor: split the MinMax aggregation family into Min and Max

[zzylol]

Why

A summary's family said MinMax and its direction rode alongside it as a string.

• build_backend_aggregation_json emitted aggregationType: MinMax and recovered "max" from an if matches! wedged inside the json! literal.
• accumulator_factory re-derived the direction with config.aggregation_sub_type.eq_ignore_ascii_case("max").
• MinMaxAccumulator carried sub_type: String and panicked on anything that was not "min" or "max"; the direction also occupied a ninth byte in its serialized form.
• catalog_resolver::supports cross-checked aggregation_sub_type against the family before admitting a candidate.

Every one of those is a place where the direction can disagree with the state it labels, and the failure is silent — a minimum answered as a maximum, not an error.

Worse, capability_for mapped both AggIntent::Min and AggIntent::Max onto ExactAgg(MinMax), so a deployed minimum summary was a legal candidate for a max_over_time read.

What

Direction is the family now, end to end.

Layer	Before	After
asap_types::AggregationType	MinMax, MultipleMinMax	Min, Max, MultipleMin, MultipleMax
asap_types::ExactStateKind	MinMax	Min, Max
asap_types::ExactReadout	Max only	Min, Max
wire	aggregationType: MinMax + aggregationSubType: max	aggregationType: Min/Max, sub-type empty
accumulators	MinMaxAccumulator { sub_type: String }	MinAccumulator / MaxAccumulator
keyed accumulators	MultipleMinMaxAccumulator { sub_type: String }	MultipleMinAccumulator / MultipleMaxAccumulator
rollup index	RollupReduction::Max	RollupReduction::{Min, Max}

• AggregationType::from_str rejects the retired names (MinMax, MultipleMinMax, min_max, …) rather than guessing a direction. There is no safe guess, and a wrong one is silently wrong.
• Each accumulator answers exactly one Statistic, refuses to merge with the opposite direction, and serializes without a direction byte.
• min_over_time gets the derived-rollup fast path max_over_time already had. Which rollup a pane feeds follows from the accumulator's type instead of from a sub_type string that had to agree with it.
• capability_for maps AggIntent::Min → ExactAgg(Min) and AggIntent::Max → ExactAgg(Max); a new test pins that neither satisfies the other.

Planner pin

Needs ASAPPlanner's own split (ExactKind::MinMax → Max alongside the existing Min), so the four ASAPPlanner deps move ca7546d → 029ff2f — ProjectASAP/ASAPPlanner#407.

Two unrelated upstream changes ride in with that pin and are handled here:

• BinaryOperator gained checked_relative_division / checked_finite_division, and avg_over_time now realizes as a guarded Sum/Count division instead of staying archive-only. avg_over_time_is_not_yet_realizable_matching_capability_for_today asserted the old outcome; it is rewritten as avg_over_time_realizes_as_a_checked_sum_over_count_division.
• PromQL count(v) is a row count upstream now (correct PromQL), and the distinct-count idiom is count(distinct_over_time(v[w])). The four HLL tests that spelled it count(v) are retargeted. Restoring a by-less cross-source merged cardinality is the second commit of feat(control_plane): adopt asap_plan::bind::implement_tree (Step A) #407.

Deliberately not in scope

summary_family_matches_exact still excludes Min/Max from the legacy family-discovery path. It excluded them because direction was unrecoverable once a summary reached AggKind::ExactAgg — a reason this PR removes — but admitting them widens candidate discovery beyond the family split. The doc comment now records that, and the test is renamed to say it is the discovery path, not the ambiguity, that keeps them out.

Compatibility

PolicyFingerprint hashes aggregation_type and aggregation_sub_type, so extremum summaries content-address differently after this change. Both sides of that wire move together in this PR; persisted streaming-configs and on-disk parts written as MinMaxAccumulator by an older build are not readable by the new byte factory.

Testing

cargo test --workspace -- --test-threads=1 in CI's configuration (ASAP_TEST_TIMEOUT_SCALE=4, ASAP_E2E_CONTROL_PLANE_BIN set), toolchain 1.98.0. cargo clippy --workspace --all-targets and cargo fmt --check clean.

Everything green except six asapquery_compatibility_process_e2e tests. Those six fail identically on unmodified origin/main (b1a58ca, pin ca7546d) in the same configuration — verified against a pristine baseline worktree, not assumed:

collector_free_profile_serves_complete_matrix_and_falls_back_exactly
durable_summary_process::persisted_summary_restarts_without_live_reregistration
registered_temporal_topk_cms_heap
registered_temporal_topk_count_sketch_heap
repeated_dashboard_executes_multiple_selected_panes
univmon_erp_process::measured_readout_evidence_selects_and_executes_univmon

They are pre-existing on main in this environment and are not touched by this change.

🤖 Generated with Claude Code

[milindsrivastava1997]

Does this take care of min_over_time compilation from #701 ?

[zzylol]

min_over_time was taken care by a previous pr