[FEATURE] Don't charge the usage cap for context re-sent after a cap-interrupted session

Preflight Checklist

• [x] I have searched existing requests and this specific angle hasn't been requested yet
• [x] This is a single feature request

Closest existing issues, none covering this angle: #81359 (usage drain from restart storms — same symptom, different cause), #56978 (graceful handling mid-limit — about the interruption, not its cost), #76118 (instruction files reloaded unnecessarily — one contributor, not the mechanism).

Problem Statement

When a session is cut off by a usage limit, the work cannot continue in that session. The next session re-sends the entire startup context — CLAUDE.md files, memory index, handoff/state files — and then re-derives the project state with tool calls, because the assistant has no memory of what the previous session already established.

That restoration is charged against the same usage cap that caused the interruption.

Measured on my setup (Claude Code desktop, Windows, subscription plan):

| what | measured |
|---|---|
| instruction corpus loaded every turn (2 CLAUDE.md + project rules + memory index + handoff) | ~70 KB ≈ 18k tokens |
| sessions per day that ended without completing their work | ~12 (36 counted over 3 days, from transcripts) |

The tool-call re-derivation is the expensive half and it is not cacheable: in the session I am writing this from, the startup context already told me a CI job was failing, and I still spent 8 tool calls rediscovering why — output that is new content every time, and that invalidates the prompt cache from that point on.

From a subscription user's point of view the loop is: the cap interrupts the work → continuing requires rebuilding state → rebuilding state consumes the cap. The user pays twice for the same context, and did not choose either the interruption or the rebuild.

Proposed Solution

When a session is resumed after a usage-limit interruption (not a voluntary restart), context that is byte-identical to what was already sent in the interrupted session should not be charged against the cap — or, at minimum, should be charged only at the cache-read rate when it is a cache hit.

Minimum viable version if the above is too broad: surface the split. Show how much of the current window went to restoring prior state versus doing new work. Right now that number is invisible to the user, so the cost is unarguable and unmeasurable from the outside.

Alternatives Considered

• Shrinking the instruction corpus. Done — 56 KB → 40 KB in one pass. Helped marginally, because the dominant cost is tool-call re-derivation, not the files.
• --resume instead of a new session. Helps only inside the 1-hour prompt-cache TTL. A session killed in the evening and resumed the next morning pays full price.
• Writing handoff notes before dying. Already automated here, and it addresses losing the work, not the cost of reloading it.

Additional Context

The two complaints usually reported together — "an interrupted session can lose work" and "a new session burns tokens reloading old work" — are one problem: the second is caused by the first. Fixing the charging of resumed context would remove the incentive to keep sessions artificially alive, which is itself a driver of the restart storms described in #81359.