Optimizer: real N_g via Prometheus profiling, hints fallback

[milindsrivastava1997]

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

• Add label_group_count: f64 to CandidateConfig (not AQE — anticipates Phase 3 sharing where a config's label set can diverge from any single AQE's), replacing the hardcoded 1.0 in cost_model.rs::ingest_cost/query_cost.
• Profiled once per AQE (batched before enumerate_candidates, stamped onto every candidate it generates for that AQE) — not once per candidate; the count is identical across an AQE's whole param grid.
• Data source: live Prometheus query (e.g. count by (labels...) (metric)) alongside the existing build_schema_from_prometheus in prometheus_client.rs, tried first.
• Fallback: extend MetricDefinition (the metrics: hints block) with an optional label_group_count hint, same priority order as the existing label-schema hints (Prometheus wins when available, hint fills the gap otherwise). Keeps asap-optimizer-cli offline-testable.

[milindsrivastava1997]

Implementation plan discussed:

• No new PromQL query type needed: fetch_labels_for_metric already calls /api/v1/series with match[]=<metric> and gets back every matching series' full label set. Add profile_label_group_count(url, metric, spatial_filter, grouping_labels): same /api/v1/series call (match[] = metric + spatial_filter_normalized), group the returned series client-side by their grouping_labels values, count distinct groups. Refactor the shared HTTP-fetch-with-retry loop out so this doesn't duplicate the 503-retry logic. Empty grouping_labels → trivially 1 (matches today's hardcoded value, no regression for ungrouped queries).
• Profiled once per AQE (batched in pipeline.rs's run_pipeline shell right after extract_aqes), threaded through as Vec<(AQE, u64)> (paired, not a separately-indexed parallel Vec) rather than re-profiled per candidate.
• Total miss (no live Prometheus data AND no metrics: hint): drop candidates using non-subpopulation-aware sketches for that AQE, consistent with Optimizer: param-aware atomic costs from sketch-bench #524's "missing data → drop the candidate" policy — defaulting to 1.0 would silently understate a capacity-planning number. Subpopulation-aware candidates (CMS, MultipleSum, etc.) and EXACT are unaffected.