Capability-matching fallback can't resolve self-keyed CountMinSketchWithHeap top-k #501

Found while adding SpatioTemporal top-k detection (#498, part of #497).

find_compatible_aggregation (asap_types::capability_matching) treats
CountMinSketchWithHeap as always multi-population for Statistic::Topk:
it unconditionally looks for a paired key aggregation
(SetAggregator/DeltaSetAggregator) on the same metric
(is_multi_population_value_type / the key_agg lookup in
find_compatible_aggregation). It has no notion of a self-keyed heap —
that only happens today through the query_config template path
(find_query_config_sql → matches_sql_pattern, then
get_aggregation_id_info's single-aggregation-reference case sets
aggregation_id_for_key == aggregation_id_for_value).

Consequence: a SpatioTemporal-classified top-k query (SELECT k, COUNT(v) ... GROUP BY <subset> ORDER BY ... LIMIT n over a window spanning >1 scrape
interval, since that's what makes it classify as SpatioTemporal at all) that
has no matching query_config template fails to resolve via the
capability-matching fallback — even when a single precomputed sketch already
spans the query's exact window and could serve it self-keyed, with no merge
or key aggregation needed.

Repro: spatiotemporal_query_detects_topk_and_resolves_self_keyed_heap in
asap-query-engine/src/engines/simple_engine/sql.rs only passes because it
supplies a matching query_config template. Swapping to an engine with no
query_config (empty templates, only the AggregationConfig) reproduces the
failure with:

capability matching: multi-population value agg requires a key agg (SetAggregator/DeltaSetAggregator) but none found