feat(status): hide cache section on backends that don't report it

[claudiusthebot]

Summary

/status currently prints Cache 0% hit · Read 0 Write 0 on backends that don't report cache telemetry (Codex when no real cache hits, agy entirely), which reads as "the backend has no cache hits" when the truth is "the backend doesn't report cache usage at all." This adds a per-backend capability flag and renders nothing when there's nothing to render.

Changes

Capability flag on QueryBackend (src/core/types.ts):

cacheMetrics?: "none" | "read" | "readwrite";

Shared buildCacheDisplay() (src/frontend/status-context.ts): returns null when the backend's cacheMetrics === "none", otherwise a CacheDisplay { hitPct, read, write, showsWrite }. Frontends drop the entire Cache block when null.

Per-backend declarations (each factory.ts):

• Claude SDK / Kilo / OpenCode → "readwrite" (full telemetry)
• Codex / OpenAI Agents / Antigravity → "read" (provider reports cached input only, no write side)
• agy → "none" (Gemini CLI doesn't expose cache counters)

Frontends rewired — Telegram, Discord, Teams, Terminal all use buildCacheDisplay(). showsWrite controls whether the write count is rendered.

Hit-pct formula correction

While restructuring, caught a regression that the initial buildCacheDisplay would have shipped: the helper used read / (input + read + write) as the denominator. That's the pre-PR-#11 bug — cache_write is tokens being written to cache this turn, not served from it, and including them dilutes the hit ratio every time the cache is being warmed.

Now matches the canonical formula in src/backend/shared/usage.ts:cacheHitPercent and the existing Telegram inline calculation: read / (input + read). Three places, one rule.

Tests

src/__tests__/status-context.test.ts — 5 new cases:

• cacheMetrics: "none" → returns null (block hidden)
• cacheMetrics: "read" → write zeroed, showsWrite: false, correct hit-pct
• cacheMetrics: "readwrite" → explicit assertion that cacheWrite doesn't dilute hit-pct (this is the formula-regression guard)
• Zero-effective-input edge case
• Mode-"read" ignores any reported write count

status-context.test.ts 7/7 ✅ · terminal-renderer.test.ts 59/59 ✅ · npx tsc --noEmit clean · npm run lint no new warnings · prettier --check clean across touched files.

What this fixes in practice

On Codex with cached_input_tokens = 0 (typical mid-session before any prompt-cache hits land), /status previously displayed Cache 0% hit · Read 0 Write 0 — visually identical to "I have a working cache that just isn't being hit." Now Codex still shows the Cache block (it does report reads when they happen), but on agy — which exposes nothing — the block disappears entirely instead of lying.

For Claude SDK / Kilo / OpenCode the display is unchanged in behaviour (full read+write), but the hit-pct formula correction makes it match the shared usage helper and the historical 5560eea fix.

Closes the "Maybe we can open a PR so that the caching information will show dynamically if the backend advertises support for it" ask from chat earlier today.