[zzylol]

Why

The MVP Collector must consume ASAPQuery's compiled physical plan rather than parse query intent or choose a sketch locally.

What

Adds a strict Rust CollectorPlan decoder/validator, behavioral tests, and documentation for the implemented consumption boundary.

How

Decode the versioned plan, validate target/materialization fields as one atomic contract, derive stable aggregation identity, and expose only fully supported configurations.

Before this PR

Collector configuration was described aspirationally, but there was no typed runtime consumer for the compiled plan.

After this PR

Supported compiled materializations can be validated and converted into Collector runtime configuration; malformed or unsupported plans fail closed.

Evidence

Execution example: integration tests cover valid plan consumption and malformed/unsupported rejection. Visual and performance evidence are not applicable.

Verification

• Unit/integration tests: cargo test --manifest-path asap-precompute-rs/Cargo.toml --test collector_plan — passed.
• End-to-end tests: transport activation is staged in feat(collector): activate compiled plans through OpAMP channel #562 and feat(collector): bridge OpAMP physical plan messages #563.
• Other checks: Rust formatting and git diff --check — passed.

Architectural decisions

ASAPQuery owns physical planning; Collector performs strict validation and execution only.

Limitations and follow-up

Stacked on #560. This PR does not yet connect the decoder to the production OpAMP transport.

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: