feat(control-plane): publish compiled physical plans

[zzylol]

Why

The MVP needs compiled physical plans to reach the intended Collector and become active before the backend treats deployment as successful.

What

Publishes target-specific CollectorPlan messages over the shared OpAMP capability, installs the matching typed BackendPlan, and requires exact plan/version application status.

How

Preflight Collector identity and capability, publish the compiled custom message, install the backend plan, and fail closed on disconnect, timeout, rejection, missing capability, or non-matching acknowledgement.

Before this PR

Physical plans could be compiled but not delivered through the production Collector control channel, and activation was not proven.

After this PR

The control plane reports success only when the targeted Collector acknowledges the exact compiled plan version.

Evidence

Execution example: OpAMP tests cover capability discovery, per-agent publication, exact-version acknowledgement, rejection, timeout, and disconnect. Visual and performance evidence are not applicable.

Verification

• Unit tests: cargo test -p control_plane — 715 library and 28 binary tests passed.
• End-to-end tests: compile-and-publish endpoint exercises preflight, backend installation, publication, and acknowledgement.
• Focused tests: OpAMP and physical compiler suites — passed.
• Other checks: cargo check -p control_plane and git diff --check — passed.

Architectural decisions

Uses a versioned custom OpAMP message instead of full-YAML configuration so the wire payload is the typed physical-plan contract.

Limitations and follow-up

Stacked on #451. Collector transport counterpart: ProjectASAP/ASAPCollector#563. Lifecycle guarantees are added in #453.

Human review — do not complete with an agent

• The MVP boundary is correct.
• New conceptual layers or public interfaces are necessary.
• The before/after description matches the intended product behavior.
• Human reviewer:
• Decision and rationale: