feat(collector): bridge OpAMP physical plan messages

[zzylol]

Why

The MVP needs the real Collector distribution to receive compiled plans through OpAMP, apply them in process, and return exact-version status.

What

Registers io.projectasap.collector-plan.v1, routes custom messages into the typed plan channel, applies them through Poll/Ack, publishes plan_status, rejects dual control sources, and makes shutdown/retry behavior safe.

How

Bind the configured OpAMP extension to one identified Collector, validate before activation, retry when the SDK send slot is pending, and cancel transport I/O before joining the apply loop.

Before this PR

The typed channel existed only as a library boundary; the production contrib processor did not bridge OpAMP messages to runtime application.

After this PR

A targeted custom message reaches the runtime, and APPLIED is emitted only after the exact version is acknowledged.

Evidence

Execution example: bridge tests cover message routing, status publication, pending-send retry, identity validation, dual-source rejection, and shutdown deadlock regression. Visual and performance evidence are not applicable.

Verification

• Unit/integration tests: go test ./controlchannel and go test -race ./controlchannel — passed.
• End-to-end component tests: asapedgeprocessor full suite and focused race tests — passed.
• Distribution evidence: OCB generation/link and local replaced build succeeded; ./asap-otel --version reported 0.141.0-dev.
• Other checks: module metadata contains the local ASAP processor/precompute modules and OpAMP custom-message module.

Architectural decisions

Uses typed custom OpAMP messages rather than full Collector YAML; only one control source may own plan application.

Limitations and follow-up

Stacked on #562; backend counterpart is ProjectASAP/ASAPQuery-backend#452. Full verification used a temporary test-only combination of existing split DDSketch/HLL sketchlib commits, then restored the checkout; no sketchlib change is included.

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: