feat(planner): estimate CPU, memory, and scan costs analytically

[zzylol]

Why

Closes #323.

Planner cost annotations previously counted logical structure. A node count has
no CPU, memory, or I/O meaning and can rank a repeatedly scanned exact plan as
cheaper than a retained summary. This stacked PR supplies a resource-dimensional
model for the data-at-rest case and uses it for candidate selection and export.

This PR is stacked on #296 because it uses that PR's typed cost annotations and
viewer presentation.

What

• Model CPU operations, peak live memory, and source/disk scan bytes.
• Calibrate those dimensions with explicit, versioned deployment coefficients.
• Cost exact Count, exact Quantile, count-ranked Top-K, and supported sketch
  implementations from concrete cardinalities, widths, and sketch parameters.
• Compose manually supplied physical DAGs with shared-node deduplication,
  execution multiplicity, and liveness-based peak memory.
• Make unavailable estimates fail closed during selection and export.
• Export reproducible inputs, resource totals, calibration, baseline, benefit,
  and model provenance.

The implemented deployment scope is explicitly DataArrival::AtRest.
ContinuouslyIngesting, Mixed, and Unknown are unavailable rather than
being treated as one snapshot build.

How

The resource vector is:

ResourceEstimate {
    cpu_ops,
    peak_memory_bytes,
    scan_bytes,
}

Calibration produces the ranking objective:

cost = cpu_ops * cost_per_cpu_op
     + scan_bytes * cost_per_scan_byte
     + peak_memory_bytes * cost_per_retained_byte

For the compact planner bridge, raw execution scans and rebuilds exact state on
every evaluation. A sketch scans the fixed snapshot once, builds retained state,
and serves later reads from that state. evaluation_count is derived from query
recurrence over a finite horizon when the canonical workload adapter is used.

The standalone physical-DAG estimator:

• charges each reachable physical node identity once;
• distinguishes Once from PerEvaluation execution;
• keeps retained state live across the horizon;
• releases transient output buffers after their final consumer; and
• rejects duplicate IDs, missing children, cycles, and inconsistent execution
  edges.

Missing statistics, arithmetic overflow, parameter mismatches, unsupported
algorithms, and unmodeled summary merge/subtract/delete/join operations return
an unavailable estimate. Structural cost is never used as a fallback.

Before this PR

Candidate and viewer costs could be derived from structural node counts. They
did not explain how many source bytes were scanned, how much operator state was
live, or how repeated evaluation changed the result.

After this PR

For supported data-at-rest shapes, the planner compares exact and summary plans
over the same fixed snapshot, workload horizon, and calibration. Unsupported or
incompletely evidenced plans remain pre-ASAP and are rendered as Not estimated.

The compact automatic bridge intentionally supports only:

• an unfiltered source scan followed by one Count or Quantile aggregation; and
• canonical TopK(Count GROUP BY key) over an unfiltered scan.

Other physical operators can be evaluated through the standalone DAG API when
their complete statistics are supplied, but arbitrary QueryExpr/SummaryExpr
lowering is follow-up work.

End-to-end evidence

Query:

SELECT service, COUNT(*) AS frequency
FROM metrics
GROUP BY service
ORDER BY frequency DESC
LIMIT 10;

The comparison uses a fixed 6.4 GB snapshot containing 100,000,000 rows and
100,000 distinct services, evaluated 100 times. The selected implementation is
one global CMSWithHeap keyed by service, not one CMS per service and not a
CMS followed by an exact Top-K heap.

Scan(metrics)
  -> CMSWithHeap(key=service, width=272, depth=5, heap_size=10)
  -> Top-K readout

Complete plan	CPU ops	Peak memory	Source scan	Calibrated cost
pre-ASAP hash aggregate + exact heap Top-K	20,040,000,000	5,600,400 B	640,000,000,000 B	26,440.0056004
post-ASAP global CMSWithHeap	1,000,001,500	11,040 B	6,400,000,000 B	1,064.00151104

Under the stated calibration, the modeled benefit is 25,376.00408936 cost
units, or 95.98%. The evidence is a deterministic execution/export example;
visual screenshot evidence is not applicable to this non-visual planner layer.

Verification

• cargo test --workspace --no-fail-fast
• cargo clippy -p asap-aware-mapping -p asap-devtools --all-targets -- -D warnings
• python3 -m unittest discover -s tools/dag-viewer -p 'test_render.py'
• git diff --check

Coverage includes hand-checked formulas, monotonicity, recurrence/horizon
derivation, stale evidence, data-arrival rejection, physical-DAG validation,
shared scans, liveness, build-once versus per-evaluation work, exact baselines,
Top-K fusion and query-derived k, unsupported lifecycle operations, and
fail-closed final selection/export.

Limitations and follow-up work

• No continuously maintained or mixed-arrival cost is claimed.
• The planner does not yet recursively lower arbitrary query and summary DAGs.
• Filter selectivity, join cardinality, spill, network, and deployment telemetry
  require explicit providers or later model dimensions.
• Empirical sketch-bench calibration and workload-wide configuration assignment
  are separate follow-up layers.

[milindsrivastava1997]

Curious, does this account for cost and deployment models for both "data at rest" vs "data streaming in with incremental summary maintenance"?

[milindsrivastava1997]

If it helps, ASAPQuery has a cost formulation. Both these docs should be consistent with each other, although they were created at different times. (They need to be de-duped).

• https://github.com/ProjectASAP/ASAPQuery/blob/main/.design_docs/sketch-config-optimization-formulation.md
• https://github.com/ProjectASAP/ASAPQuery/blob/main/.design_docs/optimizer-mip-formulation.md

[zzylol]

Curious, does this account for cost and deployment models for both "data at rest" vs "data streaming in with incremental summary maintenance"?

This PR aims for data at rest, and not yet the streaming / incremental version.

[milindsrivastava1997]

Got it, so @Selvomega should sanity check whenever this is ready. Thanks