[zzylol]

Why

Validated plans need an atomic in-process activation channel with exact acknowledgement semantics before the production OpAMP bridge can safely expose them.

What

Adds the Go physical-plan decoder, queues validated plans through OpAmpChannel, delivers each version once, and reports APPLIED only for the matching runtime acknowledgement.

How

Validate the entire target-specific plan before replacing pending state; reject malformed, stale, duplicate, wrong-target, unsupported, or uncertified TopK plans; share language-neutral aggregation IDs with Rust.

Before this PR

There was no strict Go activation boundary, and partial or mismatched configuration could not be tied to an exact runtime acknowledgement.

After this PR

Only a fully validated plan becomes pending, and control-plane status identifies the exact version the runtime applied.

Evidence

Execution example: channel tests cover delivery-once, exact Ack, rejection, and preservation of the last valid pending plan. Visual and performance evidence are not applicable.

Verification

• Unit tests: go test ./controlchannel — passed.
• Integration tests: Rust CollectorPlan test — 5 passed.
• Other checks: Rust formatting and git diff --check — passed.
• Full go test ./...: blocked by pre-existing split sketchlib feature APIs; see limitations.

Architectural decisions

Whole-plan validation is atomic and fail-closed; the Collector does not parse PromQL or re-plan.

Limitations and follow-up

Stacked on #561. The production contrib transport bridge is #563. Full Go verification needs the referenced sketchlib feature branches combined upstream.

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: