docs: design doc for planner-layering stage components, algorithms and code interfaces

[zzylol]

Why

planner-layering.md defines the planning stages, passes and algorithms. Nothing explains how they are actually built: which components implement each stage, how the implemented algorithm runs, and where it differs from the design. Developers need that before they can extend a stage or compare it with the design.

What

This PR adds a design doc, docs/design_docs/planner-layering-components.md, and links it from docs/design_docs/README.md. It describes main @ 80fc72e1 in planner-layering.md's stage order. No code changes.

How

The doc opens with a pipeline diagram of the types passed between stages and pseudocode for the top-level run. Each stage then gets three parts:

1. Core components: what each component is and does.
2. Core algorithm: pseudocode for what is implemented, mapped to the design's algorithms, followed by the differences from the design.
3. Code interface: short verbatim signatures, inputs → outputs.

The stages covered:

• Stage 0, query-language frontends.
• Stage 1, logical ASAP-aware optimization:
  • Pass 1, including whole-expression top-k candidates.
  • Composition with sizing per target, and symbolic guarantee composition.
  • Pass 2's identical-expression rule (Next Closure over sharing groups), within a lazy enumeration.
• Stage 2, physical ASAP-aware optimization: operator implementation and materialization assignment.
• Stage 3, plan selection:
  • The output-level accuracy check: counter weights confirmed, statistics bound, deployment evidence.
  • Per-second pricing with retained-state memory, and the ranking.
• Stage 4, execution: the hand-off.

It ends with a few lines on tooling and legacy code, and design-level notes on what is not implemented yet.

Before this PR

Mapping a design stage to code meant reading the module docs of asap-aware-mapping and asap-types. There was no single description of how the implemented algorithms compare with the design, such as Pass 2's two unimplemented rules or Stage 2's single materialization option.

After this PR

One design doc answers, stage by stage:

• what the components are;
• how the algorithm runs today;
• where it falls short of the design;
• which functions and types to call.

Example (Stage 1 Pass 2, as the doc presents it):

identical_expression_variants(roots, groups):
    for each closed subset S of the sharing groups, in binary-counter order:
        emit roots with every group in S made one node serving all its consumers

Verification

• Every repository path, type and function name in the doc was grepped on origin/main @ 80fc72e1 and exists. The exceptions are the design-doc terms LogicalDAG, CandidateLogicalDAGs and MATCH.
• Every non-comment line of the Rust excerpts matches the source exactly.
• Links resolve to existing files and planner-layering.md headings.
• Screenshots and measurements: not applicable (documentation only).

🤖 Generated with Claude Code

[zzylol]

Based on planner-layering.md doc, should the accuracy model in Stage 1?