Fix PromQL count semantics and verify sample-count / sketch weight invariants #405

PromQL counting must remain independent of sample values before broader metrics-platform rollout (including TurboProm). A manual audit of roughly 50 queries reported:

• count(up) on three live series with values {1,1,1} must return 3, and remains 3 for {1,1,0}. Current ASAPPlanner main lowers it to Cardinality { col: None }, incorrectly expressing distinct values (1 and 2 respectively).
• count_over_time(up[5m]) must return 10 for each series scraped ten times, whether its values are all 1, 0, 3, or negative. The reported value-sum behavior gives 10, 0, and 30. Current frontend already emits Count here, but physical CMS/CountSketch candidates still encode the sample-value column as the update weight (SummaryUpdate::column), with an unknown/signed domain.
• Negative sample values must not become negative CMS update weights. Counts use unit weights; value-weighted sketches require supported weight-domain guarantees or exact fallback.

Acceptance:

• Fix both simple and recursive count lowering, including grouped/nested expressions, without changing SQL distinct-count semantics.
• Add regression coverage demonstrating counts are invariant under repeated, zero, and negative sample values.
• Verify temporal counting and CMS weight-domain handling; clearly distinguish planner tests from production-process E2E coverage.

Backend coverage follow-up: existing hand-built HLL fixtures explicitly map count(metric) to cardinality, so they are not valid PromQL semantic oracles. Track production integration in ProjectASAP/ASAPQuery-backend#503 and #489.

References: Prometheus aggregation operators, range aggregation functions.