docs(architecture): define Planner and downstream physical boundary

[zzylol]

Why

Lifecycle policy, planner-visible realization choice, provider identity, and concrete executor deployment are different concepts. The integration boundary must allow workload-specific physical feedback without moving backend implementation or cluster placement into ASAPPlanner.

What

Add a self-contained boundary design document for ASAPPlanner, ASAPQuery-backend, ASAPCollector, and the ASAPQuery data plane.

Ownership

• ASAPPlanner owns logical query rewrites, summary family/parameters, accuracy, lifecycle candidates, planner-visible realization candidates, and final evidence-backed selection.
• A downstream physical provider enumerates feasible complete implementations and returns a stable physical identity plus cost/accuracy evidence for each candidate.
• ASAPQuery-backend owns concrete library/operator choice, pane layout, placement, sharding, storage, materialization identifiers, and workload-level assignment.
• ASAPCollector and the data plane validate and execute the compiled projections and report measurements back as future planner evidence.

The selected physical identity is retained as provenance and as the handle for downstream compilation; Planner does not interpret it as an executor configuration.

Example

Incremental describes when existing summary state is updated. Tumbling, sliding/panes, and exponential histogram describe planner-visible window realization algorithms. Planner may choose both axes. After that choice, the backend decides how the selected framework is concretely implemented and deployed.

Stack: documentation-only, based on #336; #338 adds the window-framework candidate contract.