refactor!: plan with ASAPPlanner's stage pipeline and drop the old execution stack

[zzylol]

Stack 1/5 for executing ASAPPlanner's physical ASAP DAG (#509's output and boundary definition). Next: #819.

Before this PR

The backend selected its own plans, with its own ERP, SDS, precompute and query engines, ClickHouse, OTel and OpAMP. Each part pinned a different ASAPPlanner revision, so none of it ran the plan the Planner selects.

After this PR

The Planner selects the plan; the backend executes it as given.

• Control plane: plans a PromQL PlanningWorkload with the Planner's plan_stages (Stages 0–3) under the backend's DeploymentCapabilities (query-time retention off). It writes plan.json (InstalledPlan): the selected PhysicalASAPDAG plus the query each root answers.

  control_plane --workload examples/planner-layering-example4b.json --out plan.json
  

• Data plane: loads the plan, accepts Prometheus Remote Write, and forwards every query to Prometheus. Later PRs in the stack answer planned queries from the plan.
• Planner pin: the four crates asap-types, asap-frontend-promql, asap-plan-selection and asap-executor, pinned at the demo stack head b517fbf2 (ASAPPlanner#641).
• Examples: examples/ holds test(promql): enforce range step parity in production E2E #509's PromQL examples 1, 3a, 3b, 4a and 4b as workload JSON.
• Deleted: everything else in the old backend (−176k lines), including crates/, docs/, demos/, tools/ and the Python package.

Supersedes #788–#812, #791 and #779. Those pinned different Planner revisions and did their own selection.

Notes

• The pin is a stack revision, so the daily Planner-main sync job will fail CI until the test(promql): enforce range step parity in production E2E #509 stack reaches ASAPPlanner main.
• The Planner's wire PhysicalASAPDAG holds Rcs and isn't Send, so the data plane keeps the plan on one engine thread.

Testing

cargo test -p control_plane -p data_plane, plus fmt and clippy.

🤖 Generated with Claude Code