fix: support multi-measure per-entity schemas safely

[zzylol]

Per-entity aggregates need validated schemas that expose every measure without losing timestamp or label positions. This adds multi-measure schema derivation and keeps unsafe range-average decomposition out of semantic rewrite candidates.

What and how: multi-measure schemas replace the sample slot with the first named Float64 measure and append the others. Duplicate/colliding names, missing or invalid column references, and identity-changing count_values combinations are rejected. Single-measure behavior is unchanged; unsupported fused physical lowering reports a specific error.

Before this PR: multi-measure per-entity schemas asserted or lost outputs. The initial range-average rewrite also treated unrestricted Float64 sum/count as equivalent to avg_over_time.

After this PR: named measures resolve independently while series metadata is preserved. Range averages retain their original operation: schema compatibility and non-null samples do not prove that their sum cannot overflow. The unconditional per-entity sum/count rewrite is not offered.

Numerical evidence: official Prometheus 3.5.0 returns 1e308 for the average of [1e308, 1e308], but +Inf for sum/count; the negative case similarly returns -1e308 versus -Inf. The checked-in promtool fixture verifies all four results independently. The former interpreter that defined both sides as sum/count has been removed.

Verification: the new frontend-to-rewrite regression failed before the fix and passed afterward for plain, filtered, and subquery ranges. The official fixture passed with Prometheus 3.5.0. All 610 mapping/types library tests passed; targeted all-target Clippy with -D warnings and workspace formatting passed using Rust 1.98.0.

Reproduce the oracle with promtool test rules crates/integration-tests/tests/fixtures/avg_over_time_overflow.test.yml using promtool 3.5.0. Screenshots and performance measurements are not applicable.

Limitations and follow-up: fused multi-measure physical lowering remains unsupported. Safe mergeable range-average planning still needs an overflow-safe execution path or a proven arithmetic domain; #410 remains follow-up work. Frontends resolving named multi-measure outputs should supply an explicit scan schema to avoid aliases being inferred as source labels.

Closes #409