refactor(planner): move the pass facade into asap-planner and delete asap-aware-mapping

Move asap-aware-mapping's pass/ (OptimizationPass, StagePipeline,
PassRegistry, optimize) into crates/planner, the facade per #572, and
remove the now-empty asap-aware-mapping crate from the workspace.
PlanningModels is re-exported by the planner from asap-plan-selection.
The stage manifest guards now name asap-planner instead of the deleted
crate. Docs and comments that cited asap-aware-mapping as a crate now
name the stage crate that owns the code (#572, B4b).

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

Author: zzylol

Cargo.lock

@@ -4,7 +4,6 @@ members = [
     "crates/types",
     "crates/frontend-common",
     "crates/sql-function-catalog",
-    "crates/asap-aware-mapping",
     "crates/logical-optimizer",
     "crates/physical-optimizer",
     "crates/plan-selection",

Cargo.toml

@@ -2,7 +2,7 @@
 // (or pipe via stdin: cargo run -p asap-devtools --bin show_post_asap_ir < queries.txt)
 //
 // Lowers a batch of ad-hoc SQL/PromQL queries to pre-ASAP IR, then runs the
-// `asap-aware-mapping` pre-ASAP → post-ASAP binding pass and prints the
+// `asap-logical-optimizer` pre-ASAP → post-ASAP binding pass and prints the
 // resulting **post-ASAP IR** (the sketch-bound IR: an `OperatorNode` DAG in
 // which `ASAPOp` operators — the concrete summary family/params committed per
 // aggregate — replace the bound aggregates, while whatever the pass left

crates/asap-aware-mapping/Cargo.toml

@@ -88,7 +88,7 @@ fn tally(corpus: &str) -> Tally {
 }
 
 /// Every query that lowers, additionally run through the pre-ASAP →
-/// post-ASAP `asap-aware-mapping` binding pass (issue #98), at an
+/// post-ASAP `asap-logical-optimizer` binding pass (issue #98), at an
 /// approximate accuracy target so the sketch-selection boundary actually
 /// fires (an `Exact` target would only ever exercise the exact-accumulator
 /// arm).

crates/asap-aware-mapping/src/lib.rs

@@ -4,7 +4,7 @@
 //! Drives the full staged pipeline this issue lands: two independently
 //! lowered `OperatorNode` DAGs → `share_common_sub_dags` (stage 1,
 //! `asap-types::ir::cse`, run internally by `search_workload`) →
-//! `search_workload` (stage 2, `asap-aware-mapping`) — and asserts the
+//! `search_workload` (stage 2, `asap-logical-optimizer`) — and asserts the
 //! sharing that stage 1 decides survives into stage 2's discovered
 //! `CandidateLogicalASAPDAGs` as one genuinely shared `TargetSubDAGCandidates`, not just one shared
 //! `Rc<OperatorNode>`. This is the "real caller" the issue's landing plan
@@ -15,9 +15,9 @@
 //! Committing to one final, physically-materialized answer for a whole
 //! workload (the former `implement_workload`/`implement_workload_with`,
 //! which this test file used to drive instead of `search_workload`) is out
-//! of `asap-aware-mapping`'s scope — see that crate's `lib.rs` `## Status`
+//! of `asap-logical-optimizer`'s scope — see that crate's `lib.rs` `## Status`
 //! section — so these tests assert on the discovered `CandidateLogicalASAPDAGs` shape
-//! directly, the same way `asap-aware-mapping::replacement`'s own
+//! directly, the same way `asap-logical-optimizer::pass1::replacement`'s own
 //! `shared_aggregate_across_two_roots_gets_both_strategies_candidates` test
 //! does, just exercised through the crate's public API from this external
 //! integration-test crate.
@@ -70,7 +70,7 @@ fn duplicate_workload_queries_collapse_onto_one_memo_group() {
     // TargetSubDAGCandidates with consumer_count 2 — ASAPStrategies's one
     // ExactAggregate candidate *and* SharedSubDAGStrategy's share-vs-
     // recompute pair, exactly as `shared_aggregate_across_two_roots_gets_both_strategies_candidates`
-    // (asap-aware-mapping::replacement's own equivalent, internal test)
+    // (asap-logical-optimizer::pass1::replacement's own equivalent, internal test)
     // pins for the same fixture shape.
     let group = space
         .candidates_for_target(&space.roots[0].1)

crates/devtools/src/bin/show_post_asap_ir.rs

@@ -29,7 +29,7 @@ use asap_types::types::AccuracyTarget;
 
 use crate::pass1::exact_composition::ExactOperation;
 
-/// The deployment-extensible accuracy algebra. `asap-aware-mapping` ships
+/// The deployment-extensible accuracy algebra. `asap-logical-optimizer` ships
 /// [`DefaultAccuracyModel`]; a deployment with a proof for a composition the
 /// default rejects (a registered cross-metric conversion, say) implements
 /// this trait and passes it to

crates/frontend-promql/tests/observability/promql_corpus.rs

@@ -87,7 +87,7 @@
 //!   own set through [`RollupStrategy::new`].
 //! - **No materialized roll-up operator.** Actually building a pre-aggregated
 //!   summary/scan leaf at execution time is separate, larger work outside
-//!   `asap-aware-mapping`'s scope (see issue #254's own "Non-goal" section)
+//!   `asap-logical-optimizer`'s scope (see issue #254's own "Non-goal" section)
 //!   — this module only constructs the pre-ASAP `NonASAPOp::Aggregate`
 //!   rewrite; a `CostModel`/search engine decides whether to prefer it.
 //! - **No cross-schema reconciliation** (see "`ColumnId` comparability"

crates/integration-tests/tests/cse.rs

@@ -10,7 +10,7 @@ const FORBIDDEN_MODULES: &[&str] = &["cost_model", "recurrence"];
 const FORBIDDEN_CRATES: &[&str] = &[
     "asap-physical-optimizer",
     "asap-plan-selection",
-    "asap-aware-mapping",
+    "asap-planner",
     "asap-physical-operators",
 ];