refactor(asap-types): model aggregation kinds and subtypes with typed enums #670

This was generated by AI during triage.

Problem

AggregationConfig represents an aggregation with an AggregationType plus an unconstrained aggregation_sub_type: String. The string is overloaded across unrelated aggregation kinds: plain CMS uses sum/count, MinMax uses min/max, heap CMS uses topk while its weighting is stored separately in parameters, Increase uses values such as rate, and aggregations without a subtype use an empty string.

This makes invalid combinations representable and forces the factory, planner, capability matcher, deserializers, and tests to interpret the same strings independently. Empty-string sentinels also make it unclear whether a subtype is intentionally absent or simply missing.

Goal

Replace the stringly-typed aggregation-kind/subtype representation with a typed, discriminated model. At minimum, plain CountMinSketch must have an explicit SUM-versus-COUNT mode, and other aggregation-specific modes must not be representable under the wrong aggregation kind.

Requirements

• Define typed variants for aggregation-specific modes, including plain CMS SUM/COUNT and MinMax min/max.
• Decide how heap CMS topk and count_events should be represented rather than splitting semantics between subtype and an untyped parameter map.
• Preserve or explicitly migrate the existing serialized configuration format. Existing valid configs must remain readable during the migration.
• Move validation to the configuration seam so factories, planners, matchers, and workers consume the same typed value.
• Make absence of a subtype explicit for aggregation kinds that do not use one; do not use empty strings as implicit sentinels in new code.
• Preserve the intentional legacy MultipleSubpopulation behavior unless a separate compatibility decision is documented.
• Add behavioral tests for parsing, serialization compatibility, factory selection, and capability matching.

Non-goals

This is a representation and validation refactor; it should not change the intended SUM/COUNT behavior delivered by #505 or the heap follow-up tracked by #666.

Related: #505, #665, and #666.