cost model: caching is missing from physical cost estimation #349

Follow-up to #323.

Intuition

Most query engines cache. Run the same query twice and the second run is
nearly free: a result cache returns the stored answer, and even without one the
buffer pool / page cache serves the scan from memory. So the true cost of
answering a query N times is closer to cost(first) + (N-1) * cost(cached)
than to N * cost(first).

Our analytical model assumes the latter. The raw baseline pays a full scan for
every one of evaluation_count evaluations, which makes the sketch look better
by roughly a factor of evaluation_count. That is the wrong comparison: the
sketch's real advantage is answering different queries from one retained
state (other time ranges, other probed keys), not answering the same query
repeatedly, which a result cache already does exactly.

Where it shows up

• estimate_raw_aggregation multiplies CPU and source_scan_bytes by
  evaluation_count (crates/asap-aware-mapping/src/analytical_cost.rs:603,
  :616).
• DAG costing multiplies every ExecutionMultiplicity::PerEvaluation node by
  evaluation_count (analytical_cost.rs:357).
• The design doc lists "cache behavior" as deployment/execution-profile evidence
  (docs/design_docs/asap-aware-mapping/analytical-resource-cost.md), but
  nothing consumes it. The no-cache assumption is implicit and unversioned.

Same problem applies to experiments (#347): repeating one query N times
benchmarks the cache, not the plan. Validation needs caching disabled, or a set
of distinct queries that one summary serves but a result cache cannot.

Scope

• Add a cache profile as an explicit, versioned model input, sourced from
  deployment/execution-profile evidence. Model two effects separately:
  • result cache: an identical repeated evaluation is elided (CPU and scan);
  • buffer/page cache: scan bytes come from memory; CPU work is unchanged.
• Make "no cache" a named profile so current estimates keep working and the
  assumption becomes visible in exported annotations.
• Split demand into repeated-identical evaluations (cache-eligible) and
  distinct-parameterization evaluations (summary-servable only). Only the latter
  justifies a summary over a cache.
• Under DataArrival::ContinuouslyIngesting, bound result-cache hits by
  invalidation from arriving data; fail closed when unknown.
• Apply symmetrically: retained summary state lives in memory and must not be
  charged a storage re-read.

Acceptance criteria

• Cache profile (including no-cache) is carried through CostAnnotation
  provenance and dag_export.
• No-cache profile reproduces today's estimates exactly.
• Hit ratios derive from declared inputs (working set vs. capacity,
  invalidation rate); missing or non-finite cache evidence yields Unavailable
  or a typed error, never an assumed 0 % or 100 %.
• Result-cache and buffer-cache effects stay distinct, not one fudge factor.
• evaluation_count alone no longer drives the raw baseline.
• Tests: hand-computed examples, monotonicity in hit ratio, and sketch-vs-raw
  benefit non-increasing as result-cache hit ratio rises.
• cost model: validate analytical estimates against empirical benchmark evidence #347 experiment guidance documents the cache-disabled / distinct-query
  requirement.

Related

#323 (parent) · #345, #346 (other resource dimensions) · #347 (validation) ·
#322 (empirical feedback) · #301 (cost vocabulary)