[zzylol]

Why

ASAPQuery-backend's MVP physical compiler must consume the current ASAPPlanner lifecycle API. Stale demand types and fixture field names prevented the authoritative Planner workspace and downstream control plane from compiling together.

What

Lifecycle costing now reads normalized expected demand, and the lifecycle end-to-end fixture uses the current explicit runtime capability fields.

How

Use DemandEstimate.expected_rate directly, remove the deleted ExpectedDemand adapter, and update the fixture without changing Planner selection semantics.

Before this PR

The lifecycle code referenced removed APIs, so the latest Planner contract could not be built or consumed downstream.

After this PR

Planner lifecycle selection compiles against the normalized demand model, and downstream compilation can pin one coherent Planner revision.

Evidence

Execution evidence: the complete Planner workspace builds and tests successfully. Visual and performance evidence are not applicable.

Verification

• Unit/integration tests: cargo test --workspace --all-targets — passed.
• End-to-end behavior: summary_maintenance_lifecycle_e2e exercises the current runtime capability contract.
• Other checks: cargo fmt --all -- --check — passed.
• CI: title, format/lint, and test checks — passed.

Architectural decisions

No new public interface. This is a compatibility correction to the existing normalized-demand and lifecycle contracts.

Limitations and follow-up

Downstream adoption is staged in ProjectASAP/ASAPQuery-backend#453 and ProjectASAP/ASAPCollector#564.

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: