enhancement: reprice source-dead preserved day-slices from their cached tokens on cache bumps

[iamtoruk]

Found during 0.9.21 from-scratch verification. The partial-survival guard correctly refuses to replace a preserved day-slice when the fresh parse has fewer calls (sources pruned since sealing) — but keeping the slice also keeps its historical pricing. After a repricing wave (v29: #1118 orcarouter, #1123 copilot, #1101 etc.), days with partially-dead sources retain old rates: measured 3 days across a 200-day corpus, ~$46 total (0.15%), always under-claiming.

Preserved slices carry per-model token counts, so a cache-version bump could REPRICE them through the current tables without re-reading dead files — keeping the call-preservation guarantee AND current pricing. Needs the usual never-lose analysis (models missing from current tables keep their stored cost; never zero a priced slice).

Evidence: 2026-07-19 live-disk/fresh-install = $28.86/143 calls (agree to the cent); warm preserved = $15.29/283 calls (more calls, older prices). Fresh > warm on exactly 3 days, warm > fresh (durable value) on 19+69 days — union semantics working as shipped, this is the refinement.

[iamtoruk]

Implementation built and taken to real-corpus acceptance - and the acceptance falsified the premise, so this is parked rather than shipped.

What we found: repricing preserved slices from their stored per-model token aggregates (input/output/cacheRead/cacheWrite x current rates, recorded-cost providers excluded, never-lose guards) produces totals within ~4% BELOW the stored costs on all three motivating days (2026-07-19: $15.29 stored vs $14.68 recomputed; 08-02: $117.49 vs $112.79; 08-08: $550.00 vs $533.17). Claude rates have not changed, so the stored costs were essentially correctly priced all along - the preserved-vs-live gap that motivated this issue comes from per-call effects (call-level pricing behavior that day-level aggregates flatten, always downward). Day aggregates cannot reproduce per-call truth in principle, which makes aggregate repricing an approximation - and moving recorded money by approximation is exactly what this codebase refuses to do.

The complete implementation with all guards and 20+ tests is preserved on branch feat/1132-reprice-preserved if per-call detail retention ever lands (which would make exact repricing possible). Until then the honest state is: preserved slices keep the costs they were sealed with, and the epistemic note in the header ("includes $X preserved from expired session logs") remains the disclosure.