docs: define ASAPPlanner input, output, and workflow

[zzylol]

Why

Issue #438 shows that the current documentation exposes individual planner stages without first defining the supported end-to-end integration workflow. Callers cannot easily tell which inputs are required, when lifecycle planning is necessary, or whether PlanSpace, a ranked group, or a materialized DAG is the final output. Related terminology and API-surface ambiguity is tracked in #427, and #428.

Before this PR

A caller could discover search_workload*, cost_sorted, global_selection, and lifecycle APIs independently and reasonably conclude that each was a separate valid end state. For example, a recurring summary could be structurally selected without making clear that this does not establish that maintaining it is cheaper than exact recomputation. Window semantics, summary frameworks, physical layouts, window edges, and physical handoffs were also easy to conflate.

After this PR

The design documentation starts from one outer workflow: canonical roots and requirements enter ASAPPlanner, and PlanSpace is the canonical logical output. It then explicitly documents:

• required, optional, and optimization-specific inputs;
• the meaning and categories of evidence;
• PlanSpace, ranked views, materialized DAGs, and lifecycle-aware outputs;
• inspection, structural-selection, and lifecycle-aware workflows and their promises;
• replanning as a fresh invocation with a new workload/evidence snapshot; and
• ownership-specific vocabulary for query windows, summary frameworks, physical layouts, pane layouts, window edges, physical handoffs, and comparison scopes.

The lifecycle-aware workflow is identified as the recommended path before claiming that maintained summary state is preferable to raw execution. Physical binding, deployment, transitions, and execution remain downstream responsibilities. The document also states that public Rust visibility does not automatically make a type part of the recommended integration surface.

Renames: before vs. after

Before	After	Meaning / scope
MemoGroup	TargetSubDAGCandidates	Rust type: alternatives for one target sub-DAG, not SQL grouping
RankedGroup	RankedTargetSubDAGCandidates	Rust type: the same target's candidates in cost-model preference order, with aligned costs
GlobalSelection::materialize(root)	GlobalSelection::assemble_selected_dag(root)	Public method: assemble the selected logical DAG for one query root; no runtime materialization
materialize_with_summary_maintenance_lifecycles(...)	assemble_selected_dag_with_summary_maintenance_lifecycles(...)	Public helper: assemble the DAG and return it inside a plan with summary-maintenance decisions
“memo group” / “candidate group”	“target sub-DAG candidate set”	Design prose: alternatives for the same replaceable query subexpression
“Selection and materialization helper”	“Selection and DAG assembly”	Section name: distinguish logical DAG construction from creating stored state
“Lifecycle-aware helper”	“Summary-maintenance-lifecycle-aware helper”	Section name: explicitly identify which lifecycle is being planned
“materialized root” (logical assembly result)	“assembled Post-ASAP DAG root”	Design prose; real runtime materialized views/state keep their terminology

The four Rust API renames are source-breaking: update imports and call sites. They do not change planning behavior or the DAG-root representation.

Remaining names such as groups(), group_for(), SelectedGroup, and MaterializeSummaryMaintenanceLifecycleError are renamed separately in #457 (issue #456), not in this PR. The integration entry-point API is tracked separately in #458 (issue #453).

Validation

• git diff --check
• verified all relative links added by the document resolve locally

Closes #438
Related to #427 and #428
Related to ProjectASAP/ASAPQuery-backend#734

[zzylol]

Following up issues / actions: #453 Lib Function APIs, and create PR for renaming the interfaces and abstractions in the code. #456