feat(asap-aware-mapping): optimization-applicability rule framework

[zzylol]

Part of #33.

What this adds

crates/asap-aware-mapping/src/applicability.rs: a general, extensible applicability-rule framework — given a workload's pre-ASAP query roots, determine which known optimizations apply, where, and why.

Shape (mirrors this crate's existing extension points — CostModel, Matcher):

• ApplicabilityRule — fn optimization(&self) -> OptimizationKind + fn evaluate(&self, roots: &[(String, Rc<QueryExpr>)]) -> Vec<ApplicabilityFinding>. A new optimization gets a new impl ApplicabilityRule, no restructuring required.
• ApplicabilityFinding { optimization: OptimizationKind, location: String, reason: String } — one positive result: the optimization, a human-readable location in the workload, and a human-readable reason.
• OptimizationKind is #[non_exhaustive] — only optimizations with a real rule behind them get a variant.
• find_applicable_optimizations(roots) — the entry point: runs share_common_subtrees once (so every rule, including non-CSE ones, sees the same already-deduplicated tree implement_workload would), then evaluates default_rules(). find_applicable_optimizations_with(roots, rules) swaps in a custom rule set (e.g. a deployment-specific rule, or SketchApplicabilityRule::new with a custom CostModel).

The two real rules, and why these two

Both wrap an existing, already-correct decision procedure as a finding — neither re-derives anything:

• SketchApplicabilityRule wraps boundary::implementation_for_with (the sketch-vs-exact boundary, issue L4: implement the L3→L4 binding (AggIntent→SummaryKind) and the sketch-vs-exact boundary decision #98). For every bindable Aggregate node (same single-intent, no-HAVING shape bind::implement_tree itself requires), if the boundary decision comes back Implementation::Sketch, that's a "sketch-approximation is applicable" finding. This is literally the codebase's one existing, fully-implemented instance of "optimization applicability" — just reframed as a finding instead of a bind-time side effect.
• SharedSubexpressionRule wraps asap_types::pre_asap::cse::share_common_subtrees (issue New feature: add common sub expr elimination #212/CSE detection should run in pre-ASAP IR; post-ASAP can run a secondary pass #222/Design: pre-ASAP structural CSE via bottom-up hash-consing over Rc<QueryExpr> #223). CSE's hash-consing already decides — correctly and conservatively, gated on Schema::unique_keys — which subtrees are safe to share across a workload. Two or more workload locations ending up with the same Rc<QueryExpr> after that pass is the applicability finding for the catalog's "cross-statistic reuse" / "cross-metrics reuse" / "cross-subpopulation reuse" entries — they all reduce to the same structural question CSE already answers. Findings report the maximal shared subtree (the highest point sharing starts), not every subsumed descendant.

Both rules and the top-level entry points have real unit tests (positive and negative) in the module, built with the same kind of hand-rolled QueryExpr fixtures asap-aware-mapping's own bind.rs/boundary.rs tests already use (this crate has no front-end dependency, so no parser-based fixtures are available).

Catalog primitives deliberately left as future work

The internal catalog (ProjectASAP/internal-docs/catalog_of_optimizations.md) lists several primitives/optimizations with no implementation anywhere in this codebase today. None of these get a rule — faking one would report a finding the codebase can't back up. Full closure of #33 needs each underlying primitive to exist first; this PR's module doc has the detail, summarized here:

Catalog entry	Where a future rule would hook in
Wavelets/OMP	Implementation::Wavelet/WaveletKind types already exist but no core AggIntent dispatch or CostModel::realize_extension picks them yet
Sampling	Same story — Implementation::Sample/SamplingKind exist, unreachable from core dispatch
Deep generative compression	No Implementation/SummaryFamilyType variant exists at all yet
Roll-ups	QueryExpr::Scan's Source has no pre-aggregated/rollup leaf variant yet
Approximation frameworks for windows	TimeRange/PromqlSubquery windows are always evaluated exactly today
Function decomposition	No representation anywhere; no hook point identified
Continuous distributed monitoring	RepeatingEntry/RepetitionInterval describe that a query repeats, not any monitoring-specific decomposition
Incremental computation across time	Nothing carries state across repeated RepeatingEntry evaluations today
Delta encoding	AggIntent::Delta/IDelta are PromQL value-difference semantics, not wire/storage delta encoding; DataDistribution's doc already discusses delta-compression benefit but nothing computes/applies it — this would be a deployment-side (post-ASAP) encoding decision, not IR-level dispatch

Checks

cargo build --workspace --all-targets, cargo test --workspace, cargo fmt --all -- --check, and cargo clippy --workspace --all-targets --all-features -- -D warnings all pass clean.

🤖 Generated with Claude Code

[zzylol]

Found while auditing other open PRs for the same tree-vs-DAG class of bug as PR #243: SketchApplicabilityRule's collect_sketch_findings walked the workload as a tree, with no Rc-identity dedup — unlike SharedSubexpressionRule's register_site right next to it, which explicitly dedupes by Rc::as_ptr. A bindable Aggregate reachable via two paths after share_common_subtrees (two different roots, or two branches of one root, e.g. median(x) / median(x)) was reported as two separate "sketch-approximation is applicable" findings — even though it's bound exactly once (one CostModel::cse_share_decision per shared Rc), overstating the number of independent opportunities.

Fixed: for_each_operator_child now passes an Option<usize> Rc pointer alongside each child (None only for Concat's by-value branches, which have no Rc identity of their own). collect_sketch_findings threads a visited set across the whole evaluate() call — not reset per root — and skips re-descending into an already-visited pointer, mirroring register_site's exact rationale.

New regression test (a_shared_sketchable_aggregate_is_reported_only_once) uses the same median(x)/median(x) shape pre_asap::cse's own test for this exact scenario uses — confirmed it fails without the fix (2 findings) and passes with it (1).

cargo build/test/fmt/clippy all pass clean (444 tests, 0 failed).

[zzylol]

Superseded by the ReplacementStrategy/Cascades-Volcano search framework built out for issue #33: #259 (#251), #260 (#253), #261 (#256), #262 (#254), #263 (#252), and #264 (#257) — #264 specifically rebuilds this PR's applicability.rs as a view over the new search engine's candidate-plan space rather than its own tree-walking rules, so this PR's content is superseded rather than a dependency of that stack. Closing without merging.