refactor!: keep only deployment fields on precompute materializations

[zzylol]

Stacked on #805.

Why

Installed precompute plans still described each stored output's computation
twice: once as the Planner physical DAG that now runs ingest (#796/#797/#800),
and again as backend fields on PrecomputeMaterialization (aggregation_type,
parameters, spatial_filter, aggregated_labels, …) that were cross-checked
against the DAG. The Planner DAG is the only computation definition; the backend
keeps deployment facts. The owner accepted that all old plans become invalid
(development stage, no migration).

What

• PrecomputeMaterialization keeps only deployment fields: stored output id,
  source binding, grouping, cadence and window layout, retention, semantic
  fragment.
• Removed: aggregation_type, aggregation_sub_type, parameters,
  spatial_filter(_normalized), aggregated_labels, rollup_labels,
  original_yaml, accumulator_spec(), sample_update_rule(), plus
  PolicyRegistry and RoutingIndex.
• Computation facts now come from the Planner DAG: the stored state family is the
  full Planner SummaryFamilyType in StateSchemaContract (validated against
  the producing DAG node); input filter, item label and the PromQL right-closed
  pane rule are read from the producer via PrecomputePlan::summary_producer /
  population_filter.
• stored_output_id is assigned explicitly from deployment fields plus the
  producer's computation.
• Install-time validation rejects a stored output whose producers disagree on
  population or update, and a raw output with no Planner producer (previously
  treated as unfiltered).

Breaking change

BACKEND_COMPAT is asap-query-backend.v2 and the SummaryCatalog schema is 7.
Plans from earlier builds fail to decode with a version error (tested).

Before this PR

PrecomputeMaterialization { aggregation_type, parameters, spatial_filter, … }  ⇄  Planner DAG (cross-checked)

After this PR

PrecomputeMaterialization { stored output id, source, grouping, windows, retention, semantic fragment }
Planner DAG: the only computation definition

Known follow-ups (from independent review)

• Plans decode through a JSON value to check the version first; YAML round-trips
  may not decode (plans are installed as JSON).
• Compiler and runtime derive item labels differently; OTLP series may get an item
  label for keyed non-top-k sketches.
• DAG documents are decoded on each lookup; the state-family lookup is linear.
• A few design docs still mention removed fields.

Validation

cargo fmt --check, cargo clippy --workspace --all-targets -- -D warnings,
cargo test --workspace (lib, integration and process e2e targets). An
independent reviewer found two install-time gaps (conflicting producers; missing
producer), both fixed with regression tests that fail without the fix.

🤖 Generated with Claude Code