feat(promql): compile and execute count/avg aggregation families from the ASAPQuery matrix

[zzylol]

Audit evidence

The PR-derived ASAPQuery PromQL matrix includes count, avg, count_over_time, and avg_over_time (especially ASAPQuery #700). Against current main, the backend-local physical compiler:

• compiles count_over_time(m[1m]);
• panics in stage config emission for count(m) because the selected sketch algorithm has no backend mapping;
• rejects avg(m) and avg_over_time(m[1m]) because no executable Collector lifecycle is selected.

This is a warm-path capability gap, not a parser gap. Parent matrix: #501.

Required behavior

• Compile and execute all four shapes for instant and range requests, with optional by (...) where ASAPQuery supports it.
• Represent avg as a semantics-preserving sum/count composition and retain both materialization/readout dependencies.
• Map count to an executable exact or sketch family without an unreachable! panic; unknown families must fail closed.
• Preserve labels, float result type, timestamps, empty-window behavior, and Prometheus NaN/divide-by-zero semantics.

Acceptance tests

Add these cases to the backend process differential E2E matrix, assert parity with Prometheus, and assert data_source: warm for both /api/v1/query and /api/v1/query_range.

[zzylol]

Additional diagnosis from the implementation pass: count(m) is a Planner Cardinality intent with candidates [Hll, Theta, Kmv]. Under the current epsilon+delta requirement, HLL is not selected as a legal lifecycle winner; Theta wins abstract planning and then reaches the backend emitter, which panics because this runtime has no Theta accumulator/wire mapping. Simply reordering HLL is insufficient: filtering Theta/KMV leaves no executable lifecycle. The fix therefore needs both (1) runtime-capability filtering before plan selection and (2) an accuracy contract HLL can legally satisfy (or an exact Count realization for this PromQL shape). This is now guarded by the fallback row in PR #506.