stage_pipeline: write the memo after each step, the selected choice and the enumeration #1003

Problem, by example

Example workload: one query, evaluated every minute, with max_error 0.01 and failure_probability 0.001:

avg by (job) (quantile_over_time(0.5, data[5m]) / quantile_over_time(0.5, data[5m]) + quantile_over_time(0.9, data[5m]))

The memo the planner builds for it on main (0f7465c96), measured with LogicalMemo::from_roots, try_populate_pass1 and the expanded_memo test helper:

G2 and G3 are separate groups because share_common_sub_dags (crates/types/src/ir/cse.rs) shares a non-ASAP node only when its schema has a provable unique key, and this per-series quantile's output schema has none.

stage_pipeline --workload wl.json --out doc.json on this workload writes an asap-stage-pipeline/v1 document with the Stage 0 DAG, the selected plan's Stage 1 and Stage 2 DAGs, and the search report. None of the tables above can be read from it:

• no groups;
• no candidates per group, and no rule (CandidateOrigin) that added each one;
• no record of which candidate the MILP chose for each group.

So neither the DAG viewer nor the CI snapshots can show what each stage did to the memo.

Why

stage_pipeline (crates/devtools/src/bin/stage_pipeline.rs) serializes the stage results. It never serializes LogicalMemo or CandidateMemo (crates/logical-asap-optimization/src/memo.rs, memo/candidates.rs), and the selected plan's report holds its candidate connections, not a group → candidate map.

Proposal

Add an optional memo section to the document:

• snapshots: one per step: stage0 (after hash-consing), pass1, pass2 and concrete_states (the last runs in Stage 3 today; the Stage 1 reorganization moves it).
  • Each snapshot lists its groups. A group has id, its operator label, children, parents, queries and roots_of.
  • Each group lists its candidates. A candidate has id, implements, children, origin, budget_share, and its own nodes in the document's existing node format.
• selected_choice: the selected plan's group → candidate map.
• enumeration: count, complete and the first --max-enumerated choices (default 200), from memo::enumerate.

The section is on by default. The CI snapshots keep enumeration.count and complete but drop the choice list.

Scope and acceptance

• A stage_pipeline test on the example above: stage0 has 8 groups, pass1 has 26 candidates, and the pass1 enumeration is 343 with complete: true.
• Every candidate in selected_choice exists in the last snapshot.
• The viewer's document validator (tools/dag-viewer/stages.js) accepts documents with and without memo.

Depends on #1002 (memo → candidate DAGs).