[Bug]: Stable web client + nightly server renders Usage as all zeros, notice blames the server

Before submitting

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.

Area

apps/web

Steps to reproduce

1. Run a current t3 serve (anything after #6170, which bumped USAGE_CONTRACT_VERSION to 4) and pair it with app.t3.codes.
2. Open Usage on app.t3.codes.
3. Watch the server side: server.getUsageSummary succeeds and returns a populated summary with contractVersion: 4.

Expected behavior

The page shows the totals the environment just reported. If a version guard has to drop the data, the notice should say the web client is behind, not blame the server.

Actual behavior

Every figure on the page renders as 0, with a small notice per device: " runs an older server version and is excluded from totals."

Two things combine to cause this:

1. app.t3.codes is serving a frontend built before #6170 (2026-08-11). The deployed assets/index-*.js has no "Past 24 hours" view, its usage window key is only {sinceDay, untilDay, timeZone} (no resolution/sinceTime/untilTime), and its minified merge call is BHe(a.flatMap(GHe), 3), i.e. mergeUsage(answered, 3). It expects usage contract 3.
2. The stale guard is strict equality. usageMerge.ts does summary.contractVersion === expectedContractVersion, so a newer server fails the check exactly like an older one. Every current server replies with 4, every device gets pushed into staleEnvironments, and the merge returns the empty summary. The page renders all zeros and the notice claims the (newer) server is older.

So any user on a recent nightly who opens Usage on the hosted web app sees $0.00 / 0 tokens across the board, while their server logs show successful getUsageSummary calls. Verified end to end on my setup: the server's scan cache holds ~128M tokens over 30 days and the RPC returns them; the deployed client discards the reply.

Impact

Major degradation or frequent failure

Version or commit

Server: 0.0.34-nightly.20260819.1133. Hosted frontend: whatever app.t3.codes served on 2026-08-25 (chunks index-DjUtAiF9.js / textarea-rLmLQHqI.js).

Environment

Linux server (t3 serve on 127.0.0.1:3773) paired via T3 Connect; Firefox 153 on Linux against app.t3.codes. Same result regardless of provider; transcripts present for both Claude Code and Codex.

Logs or stack traces

# server trace: the summary request the web app then discards
{"name":"ws.rpc.server.getUsageSummary","durationMs":26.5,"exit":{"_tag":"Success"}}

# deployed app.t3.codes bundle (index-DjUtAiF9.js), merge call site:
... c=BHe(a.flatMap(GHe),3) ...   # mergeUsage(answered, 3)

# same bundle, stale filter:
... i.summary.contractVersion===t?n.push(i):r.push(i.environmentId) ...

Workaround

Use a client that matches the server's version: the web client the server itself hosts (e.g. http://127.0.0.1:3773) or a current desktop build. Both expect contract 4 and show correct figures.

Suggested fixes beyond redeploying the hosted app: make the guard tolerate or at least correctly describe a newer server (contractVersion > expected means the client is behind), and word the notice accordingly. Related: #6045 covers the separate case where an offline remembered device holds the page on the skeleton forever.

Start in usageMerge.ts and trace the Usage page's handling of the summary returned by server.getUsageSummary. Reproduce with a contractVersion 4 response and verify that the page retains populated totals, while any rejected version is described as a client/server compatibility issue rather than incorrectly blaming the server.