asap-aware-mapping: whole-plan (cross-group) cost-based selection over the search's candidate-plan space

[zzylol]

Part of #33. Builds on #263 (issue #252).

What

PR #263 built the Cascades-style candidate-plan space (PlanSpace/MemoGroup
in crates/asap-aware-mapping/src/search.rs) — one MEMO group per discovered
TargetSubDAG, holding every ReplacementSubDAG alternative any registered
ReplacementStrategy proposed for it, sharing every untouched node by Rc
rather than materializing full candidate plans.

Its final costing step, PlanSpace::cost_sorted, does not select a
plan. It ranks each MemoGroup's candidates independently and locally:

• a SharedSubtreeStrategy group is ranked via CostModel::cse_share_decision,
• a SketchFamilyStrategy group is ranked via CostModel::rank_candidates,
• any other shape keeps discovery order.

Groups never see each other's choices. There is no step that combines a
choice at one site with a choice at another site into a single workload-wide
cost, and therefore no way to pick a global optimum across sites whose
choices interact — exactly the gap docs/design_docs/asap_aware_mapping.md's
"Global Rather Than Local Decisions" section calls out:

A locally optimal choice may prevent a globally better combination. The
planner should therefore retain local alternatives until enough context
exists to compare the complete candidate plans they produce.

and the Planning Flow's last two stages ("Estimate candidate plan costs" →
"Rank or select candidate post-ASAP plans") describe. #263 built the
candidate-plan space stage; this issue is that final whole-plan
costing/selection stage over it.

Concretely, this is where axis interactions the design doc lists become
visible only at the plan level, e.g.:

• sharing a CSE'd subtree changes how many consumers a nested
  SketchFamilyStrategy site's sizing/maintenance cost is amortized across,
  so the two choices aren't independently rankable;
• a future roll-up-vs-recompute strategy's preferred choice can depend on
  which sketch family a sibling site picked.

Design (sketch — open to revision)

Given PlanSpace's groups, and an assignment of one chosen candidate per
group (defaulting to "no change" for groups with no candidates), define a
combined cost for the assignment and search over assignments for a good one,
rather than ranking each group in isolation:

• Where group choices are independent (no shared cost inputs — the common
  case per PR feat(asap-aware-mapping): search engine over ReplacementStrategy (Cascades-style memo search) #263's own convergence argument, one round for both shipped
  strategies), the existing per-group ranking is already optimal and should
  stay the fast path.
• Where group choices interact (e.g. a SharedSubtreeStrategy group's
  Share/Recompute choice changes a descendant SketchFamilyStrategy group's
  effective consumer count), the interaction needs to be visible to the cost
  computation — likely a CostModel hook that can be handed more than one
  group's chosen candidate at once, rather than each hook seeing only its
  own group's candidates. Whether that's a real bottom-up DP over the
  group/consumer graph (compose each group's chosen-candidate cost with its
  children's) or a cheaper local-search/coordinate-descent approximation is
  the open design question this issue should resolve — this crate has no
  cardinality/statistics estimation to bound a large search with (same
  constraint CSE: decide rule-based vs. cost-based framework for whether to actually share a detected common subexpression #237/feat(asap-aware-mapping): search engine over ReplacementStrategy (Cascades-style memo search) #263 already navigated), so exhaustive combinatorial
  search over many interacting groups may not be tractable as-is.
• PlanSpace::cost_sorted's existing per-group ranking should probably
  remain available (e.g. as a fallback/building block) rather than being
  discarded — it's still correct for the non-interacting case.

Depends on

#263 (needs PlanSpace/MemoGroup — the candidate-plan space to select
over) and its CostModel extension point.