capability matching: output-partitioning check is wrong for Cardinality and skipped for grouped queries #878

Found while reviewing #826. scalar_requirement_compatible (added in #826, asap-common/dependencies/rs/asap_types/src/capability_matching.rs) only guards the empty-GROUP-BY case. It also gets Cardinality wrong.

!requirements.grouping_labels.labels.is_empty()
    || requirements.statistics.contains(&Statistic::Topk)
    || config.aggregated_labels.labels.is_empty()

1. Cardinality configs are matched backwards

For SetAggregator / DeltaSetAggregator, aggregated_labels is the dimension being counted, not an internal partition.

Global SELECT COUNT(DISTINCT L2) FROM t WHERE ..., going through capability fallback:

• The correct SetAggregator config (aggregated_labels=[L2]) is rejected, because aggregated is non-empty.
• A planner-emitted DeltaSetAggregator sibling of a global CMS (aggregated_labels=[]) passes. The matcher never checks value_column, so it gets picked, and the query returns the size of the empty-key set (1) instead of the distinct-L2 count.

2. Grouped queries are not guarded

!requirements.grouping_labels.is_empty() short-circuits, so sum by (job) against a config with grouping=[job] and aggregated=[host] still matches and returns one row per (job, host).

Suggested fix

Replace the special case with one invariant in labels_compatible: the config's output partitioning (grouping ∪ aggregated for value-partitioned types) must equal the query's labels. Topk is exempt. Set-type configs, where aggregated is the counted dimension, are exempt too, and should instead be checked against the query's counted column. That covers both cases above.

Tests to add

• Global COUNT(DISTINCT L2) picks the SetAggregator with aggregated=[L2] over a DeltaSetAggregator with aggregated=[].
• sum by (job) does not match a config with grouping=[job] and aggregated=[host].