[FEATURE] Usage display should surface cache read and write token consumption

Is your feature request related to a problem?

The token counter and Plan usage display show output tokens but nothing about cache reads or cache writes. In practice, cache reads are often the dominant cost in a session — not output tokens — yet they are entirely invisible to the user.

This is not limited to large context windows or flagship models. Cache reads accumulate proportionally to context size on every model and at every plan tier. A user watching the current display has no way to understand, anticipate, or manage the costs that actually drive their bill.

Concretely: in a long agentic session, every single API call re-bills the user for the entire accumulated context at the cache-read rate. Compaction events write the full context to cache at the (higher) cache-write rate and fire automatically. Neither is visible anywhere in the UI.

Describe the solution you'd like

The session usage display should break out:

• Cache read tokens (running total and per-turn)
• Cache write tokens (with compaction events identifiable as the large discrete spikes they are)
• Output tokens (already shown)

A single aggregate "total billable token-equivalents" at current model rates would also be more useful than output tokens alone.

Additional context

This compounds #55121: sub-agent cache reads are doubly invisible — not counted in the main-thread total, and not broken out even when they are counted.

Independent analysis by community members corroborates the scale of the problem: one user documented that cache read tokens consumed 97.7% of their session costs, with actual API cost of $1.47 versus a total billed cost of $64.98 — a 44× ratio (source).

Prior art / not a duplicate

#44779 is related but scoped to 1M context + Opus + Linux, framing cache cost visibility as a niche concern. This request is general: cache reads dominate cost across all context sizes, all models, and all platforms. The visibility gap is not a special case.

#28723 is also related and platform-agnostic, but scoped specifically to Opus and the 1M context window. The problem it describes — quota depleting faster than expected with no visibility into why — is a symptom of the same root cause, but the fix is not Opus-specific or context-size-specific.