feat(control-plane): compile Planner selections into physical plans

[zzylol]

Why

The documented MVP requires ASAPPlanner selections to become executable, target-specific physical plans instead of stopping at logical selection.

What

Adds a physical compiler that lowers Planner selections into stage allocation and backend/Collector plan materializations, with focused contract tests and implementation-aligned documentation.

How

Validate the selected primitive and runtime capabilities, allocate stages with the existing allocator/emitter pipeline, and lower the result into typed plan structures without re-planning query semantics.

Before this PR

The backend could obtain a Planner selection, but there was no production boundary that compiled it into the physical plan consumed by runtime components.

After this PR

A supported Planner selection produces a validated physical plan; unsupported or incomplete selections fail closed.

Evidence

Execution example: compiler tests cover supported compilation and rejection paths. Visual and performance evidence are not applicable.

Verification

• Unit tests: cargo test -p control_plane physical::compiler::tests:: -- --nocapture — passed.
• End-to-end tests: compilation is exercised through the control-plane plan path; publication is staged in feat(control-plane): publish compiled physical plans #452.
• Other checks: cargo check -p control_plane and git diff --check — passed.

Architectural decisions

The compiler is a translation boundary: Planner owns selection semantics; the existing backend allocator/emitter owns executable stage layout.

Limitations and follow-up

Stacked on #450. This PR compiles plans but does not transport them; OpAMP publication is #452.

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: