Remove the legacy plan endpoints and the dead capability-miss loop

[zzylol]

#703 item 18, second deletion step. Stacked on #715 (which is stacked on #713) — review those first.

The finding that makes this a deletion, not a rewrite

The issue treats POST /api/v1/plan as "still fully alive". It is routed, but it has no working consumer. Both apparent ones are broken or unwired:

1. The capability-miss feedback loop never worked. The data plane POSTs a CapabilityMissPayload:

{"kind": "...", "metric": "...", "statistics": [...], "data_range_ms": 300000,
 "grouping_labels": [...], "spatial_filter_normalized": "..."}

handle_plan accepts a QuerySpec, whose accuracy_sla has no #[serde(default)]. Verified by deserializing the exact payload against QuerySpec:

missing field `accuracy_sla`

No control-plane handler accepts that payload at all — there is no capability_miss route and no field named spatial_filter_normalized anywhere in the crate. The resulting non-2xx becomes an Err that spawn_capability_miss_notify logs at WARN and drops, so the loop has been a silent no-op in production.

2. config_fetcher::ControlPlaneClient — which polls GET /plan/:metric and posts /plan — is never constructed outside its own module.

That left control_plane/tests/component_process_e2e.rs as the only real caller, and it exercises the legacy path itself.

Consequence: the three gaps that would have made porting handle_plan onto PhysicalCompiler awkward — QuerySpec::query_string being Option, the absent LifecyclePlanningInput cost evidence, and the absent window_implementations (select_lifecycle hard-errors without a concrete implementation) — do not need to be closed at all.

What goes

• POST /api/v1/plan, GET /api/v1/plan/:metric, and their handlers
• data_plane/src/drivers/control_plane_client/ entirely, plus the engine's control_plane_client field, with_control_plane_client, and both spawn_capability_miss_notify call sites
• --control-plane-endpoint and its --profile asapquery exclusion check, now unreachable
• control_plane/tests/component_process_e2e.rs and data_plane/src/tests/capability_miss_http_e2e_tests.rs
• 14 tests in main.rs covering the deleted routes
• AppState::{analyzer, planner, store, scraper, backend_routing_cache} — all unread once the handlers are gone

2,031 lines removed, 10 added.

What deliberately stays

pipeline.rs, physical/plan_cache.rs, physical/workload_planner.rs and store/ are untouched. The startup workloads.yaml pre-population (main.rs) still runs Analyzer and DeploymentPlanCompiler to fill workload_store, which handle_bootstrap_agent_config reads. That chain retires together with the collector-facing emitters in the next step; splitting it here would leave a state that does not compile.

Testing

• cargo +1.98.0 check -p control_plane -p data_plane --all-targets — clean, no warnings.
• cargo +1.98.0 test -p control_plane --lib — 705 passed, 0 failed.
• cargo +1.98.0 test -p data_plane --lib — 1193 passed, 0 failed.

Unrelated note

rustc 1.98.0 ICEs on evaluate_obligation under incremental compilation while checking this change. CARGO_INCREMENTAL=0 (or cargo clean -p control_plane) works around it. Not caused by anything here, but worth knowing if CI hits it.

🤖 Generated with Claude Code