Optimizer: auto-infer N_g from Prometheus #525

Part of #523 (Track 2: non-empirical gap 3 + empirical gap 4).

Goal

Replace the optimizer cost model's hardcoded N_g = 1 with label-group cardinality inferred from live Prometheus data.

Scope

• Add label_group_count to CandidateConfig, not AQE, so the profiled count belongs to the candidate configuration and remains compatible with future Phase 3 sharing.
• Use N_g = 1 for subpopulation-aware sketches and the profiled distinct grouping-key count for non-subpopulation-aware sketches.
• Apply the count to ingest memory and query CPU/memory costs; ingest CPU remains based on total arrival rate.
• Profile once per profile key (metric, spatial_filter, grouping_labels) before candidate enumeration, and reuse the result across the AQE candidate grid.
• Use the existing Prometheus /api/v1/series path and shared retry/fetch logic. Construct a selector from the metric and spatial filter, then count distinct grouping-label tuples client-side.
• Cache series data so multiple AQEs with the same metric/filter do not repeat the expensive fetch.
• An empty grouping-label set has N_g = 1. Empty or unavailable Prometheus data must never become N_g = 0.
• If cardinality is unavailable, retain EXACT and subpopulation-aware candidates while dropping non-subpopulation-aware candidates, consistent with the missing-data policy in Optimizer: param-aware atomic costs from sketch-bench #524.

Follow-up

The offline, dataset-backed implementation is tracked separately in #693. Both implementations should feed the same optimizer profile interface; #693 should not require Prometheus.

Acceptance criteria

• Prometheus-derived cardinality changes non-subpopulation-aware candidate costs proportionally.
• Subpopulation-aware and EXACT candidates are unaffected.
• Prometheus data takes precedence over any fallback metadata.
• Selector construction, retries, caching, empty results, and distinct grouping-key counting are covered by tests.