docs: backend on ASAPPlanner: boundary, comparison with ASAPQuery, merge plan

[zzylol]

Why

The backend's design and its boundary with ASAPPlanner lived only in a shared draft. This puts them in the repo, next to the code, focused on what the merge with ASAPQuery needs.

What

docs/design/backend-on-planner-physical-dag.md, three parts:

• Boundary between ASAPPlanner and ASAPQuery-backend. ASAPPlanner decides what to compute, when and for how long, and provides the physical operator library. The backend runs the installed DAG node by node, and owns the SDS, ingestion, threads and raw data. It covers the plan_installable interface and the rules that keep the boundary.
• ASAPQuery and ASAPQuery-backend compared. A feature comparison, and where the backend's overhead came from: the executor's row layout took 68–75% of data-plane CPU, against 3–7% for the sketch kernels. Measured numbers before and after the fixes, in process and against Prometheus alone, and what still blocks a benefit.
• Merging with ASAPQuery. Seven key points, which component comes from which side, stages A–G with their status, and open decisions.

Before / After

• Before: 461 lines, including per-component internals and a full step-by-step profile.
• After: 173 lines on the three topics above. The detailed profile and per-operator design are in the git history of this branch.

Notes

• Stacked on feat(query): answer planned range queries one evaluation per step #825. Docs only; no code change.