docs: design of the backend on ASAPPlanner's physical DAG and the Planner/backend boundary

[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.

What

docs/design/backend-on-planner-physical-dag.md: overview, architecture, the ASAPPlanner/backend boundary (responsibilities, what crosses it, rules that keep it), the SDS, the precompute and query engines, evaluation (correctness results and the benefit experiment), and the implementation plan.

Two new sections before the implementation plan:

• Overhead of the data plane, compared with ASAPQuery: measured totals, a profile of where the data plane's CPU goes, the same steps run in-process on both implementations, and a ranked table of causes with evidence, ASAPQuery's handling of each step and the fix. Summary kernels are 3–7% of the data plane's CPU; the executor's row-at-a-time data path is 68–75%.
• Merging with ASAPQuery: benefits and features: a feature matrix of both implementations, which component comes from which, the boundary with ASAPPlanner, a staged plan (A–G) with measured targets, risks and open decisions. The implementation plan gains rows A–G.

Notes

• Stacked on feat(query): answer planned range queries one evaluation per step #825.
• Describes the target after the backend re-pins to ASAPPlanner's plan_installable API (ASAPPlanner [Feature] Add debugging logs for each components following the workflow of control plane and data plane for debugging #755). Summary identity, dedup and eviction stay in this repo's SDS.
• Docs only; no code change.

Update: execution engine

• New section "Execution engine: a columnar DAG executor". The data plane always executes the installed DAG node by node, for every query shape; there is no shape-matched fast path. ASAPPlanner provides the physical operator library (one columnar operator per plan-node kind, per-sample summary updaters, RawSampleSelector); this repo's execution engine runs the DAG with it.
• It specifies the batch format (selection vectors, interned series and group ids, dictionary labels), how sketch state is columnar (exact accumulators as numeric columns, fixed-size sketches in flat buffers, variable-size sketches one object per group, stored panes as immutable Arc<StateBatch>), every operator's columnar implementation, the per-sample ingestion pipeline, precompute worker threads, and the query engine (one query per thread, RwLock + Arc reads, never deep copies).
• Stage C of the merge plan is now the columnar operator library in ASAPPlanner.