fix(usage): TTL-tier cache writes and price them correctly

[mgoldsborough]

The bug

The engine cached everything at a 1-hour TTL (billed at 2× base input), but the cost model priced cache writes at the catalog's 1.25× 5-minute rate — so every dashboard and the cost script under-reported real cache-write spend by ~1.6×. Verified against the live API:

"cache_creation": { "ephemeral_5m_input_tokens": 0, "ephemeral_1h_input_tokens": 3376 }

Every write is billed at the 1h tier. The audit flagged this; this confirms and fixes it.

Why TTL should be tiered, not all-1h

After the rolling step-anchor (#401), the bulk of cache writes happen within a run — the agent loops seconds apart, and each turn re-reads the prior breakpoint almost immediately, far inside even the 5-minute window. The 1-hour premium (60% over 5-minute) buys nothing there. It only earns its keep on the stable prefix re-read after a between-runs pause (a user stepping away for minutes).

So the engine now tiers TTL by breakpoint stability:

Breakpoint	TTL	Why
system + tools (stable)	1h	One write per run; expensive to rebuild; worth keeping warm across a pause
step-anchor + tail (rolling history)	5m	Re-read within seconds inside a run; lapses cheaply after a pause while system+tools stay warm

This pays the premium only where it earns its keep — a meaningful write-cost cut on long conversations, with no loss of the #401 within-run caching (5-minute is plenty for second-apart reads).

TTL-aware costing (correct regardless of the TTL strategy)

Rather than hardcode a single rate, costing now uses the split Anthropic already returns:

• The engine captures the per-call 1-hour write portion from usage.raw.cache_creation.ephemeral_1h_input_tokens onto a new TokenUsage.cacheWrite1hTokens.
• cost.ts prices the 1h portion at 2× base and the 5-minute remainder at the catalog cacheWrite rate (which is the 5-minute rate — finally used correctly).
• cacheWrite1hTokens is tri-state: absent means "no split reported" (legacy events from before tiering, or non-Anthropic providers), which cost treats as all-1h so historical figures stay accurate. addUsage/emptyUsage preserve the absent state rather than collapsing it to an explicit 0.

This makes the cost model correct for any TTL strategy — today's tiered split, a future all-5m, whatever — with no re-fix.

Tests

• New: TTL tiering (system/tools = 1h, anchor/tail = 5m); split pricing (1h at 2×, 5m remainder at catalog rate, result strictly between all-1h and all-5m).
• Updated: existing cost tests to the 1h rate; the engine's "last user message" breakpoint test to expect 5m (it's the rolling tail now).
• verify:static green; full unit suite (3,392) green.

Follow-up (separate, in the deployments repo)

The tenant-summary.py cost script needs the same TTL-aware treatment (it has its own pricing table) so the /tenant-summary numbers match. Handling that alongside this.