Publish the authoritative summary catalog with physical plans

[zzylol]

Why

The control plane already owns the authoritative SummaryCatalog, but two publication paths passed separate plans to BackendClient, which rebuilt a second catalog from duplicated precompute definitions. That allowed descriptor identity and generation metadata to drift before installation.

Before this PR

post_physical_plan_typed accepted PrecomputePlan, TransmissionPlan, and QueryPlan separately, derived a catalog inside the transport client, rebound cloned plans, and omitted the catalog chosen by the compiler. The compatibility replanner also advertised a collector producer even though it installs backend-local state and publishes no CollectorPlan.

After this PR

Every production publication path assembles one PhysicalPlanPublication and passes that authoritative bundle to post_catalog_plan_typed. BackendClient only validates and transports the supplied catalog and its plan projections. Catalog derivation remains confined to the legacy compatibility adapter, which now models its precompute work as backend-local and therefore does not manufacture a collector producer.

Example

A ClickHouse compilation now publishes bundle.sds together with the exact precompute, transmission, and query plans that reference that snapshot. The client cannot silently replace it with a catalog inferred from legacy materialization DTOs.

Verification

• cargo check -p control_plane --all-targets
• cargo test -p control_plane --lib catalog_publication_posts_canonical_document_without_legacy_bytes
• cargo test -p control_plane --lib backend_push (15 passed)
• git diff --check

Depends on #564.

ClickHouse migration surface: construct the language-neutral PhysicalPlanPublication from the compiler-owned SummaryCatalog, PrecomputePlan, TransmissionPlan, and unified QueryPlan. External exact execution stays represented as typed query DAG nodes; no language-specific plan catalog, sidecar, or ExecutableQueryPlan is required.