Prompt cache never hits after a mid-conversation `role:"system"` message (resume and hook output), Opus 5.x / Fable

Version: 2.1.280 and 2.1.282 (macOS arm64), claude-opus-5-5, subscription auth.

What happens: when the last message of a request is a mid-conversation {role:"system"} message (hook output or attachments; with -p --resume it happens on every turn), the client places the cache breakpoint on that message. On the next request the same message is re-sent with byte-identical text but without the cache_control, and the server never gets a cache read past the stable system head. Every turn rewrites the whole conversation prefix.

Repro (stock binary): claude -p "Reply ONE" --session-id <uuid>, then four times claude -p "Reply TWO" --resume <uuid>. Per-turn cache creation/read: 87,501/0, 76,877/12,313, 78,573/12,313, 82,379/12,313, 83,571/12,313. Same on 2.1.282.

Isolation: CLAUDE_CODE_MODEL_CAPABILITIES=-mid_conv_system gives 81,418/0, 10,003/81,418, 1,618/91,421, 1,135/93,039, 1,134/94,174. Rewriting the trailing system message to role:"user" at a proxy also restores hits. Interactive sessions are affected too: warm-turn cache rebuilds ran at 11.3% over two days (about 3,000 turns), against about 2.5% before.

Also: the client's cache health check counts any cache creation as success, so the misses aren't surfaced.

Related: #47098 (closed and locked) - a different trigger in the same cache-point placement: reminder blocks before the only breakpoint on a fresh session's first request.