Capability-matching fallback mismatches topk's key aggregation #708

Problem

find_compatible_aggregation's fallback path (asap_types::capability_matching) treats CountMinSketchWithHeap (topk) as needing an external paired key aggregation, because AggregationType::is_multi_population_value_type() returns true for it. But the planner never emits a paired SetAggregator/DeltaSetAggregator for CountMinSketchWithHeap (only for CountMinSketch/HydraKLL) — topk is self-keyed, it discovers its own keys via get_topk_keys().

Effect

Only hit when a topk query isn't a literal pre-planned string (the direct QueryConfig path is unaffected and works):

• No other key aggregation on the metric → fallback matching returns None, topk goes unsupported.
• Metric has an unrelated key aggregation (e.g. a co-located sum_over_time's CountMinSketch+DeltaSetAggregator pair) → fallback wires the topk heap to that, bypassing the heap's own key discovery.

Also found

PromQL's build_query_requirements_promql always sets requirements.grouping_labels to the full label set for topk, but find_compatible_aggregation does exact-equality (labels_compatible) against config.grouping_labels — which is empty for topk after PR #706 (topk labels live in aggregated_labels, not grouping_labels). SQL's build_query_requirements_sql already documents the correct model (topk grouping is empty, labels are the sketch's internal key) — PromQL's requirements builder doesn't follow it. Possibly affects any by(...)-grouped multi-population statistic through this same fallback, not just topk — unconfirmed.

Scope

Investigation only, found while fixing #699 (PR #706). The direct pre-planned QueryConfig path is confirmed correct (unit + live differential run).