[Bug] Deterministic 500 on one conversation (claude-fable-5): every retry dies mid-stream after thinking; session unrecoverable

Bug Description

One specific conversation deterministically fails with API Error: Internal server error on every send (4/4 attempts over ~20 minutes), while concurrent sessions on the same machine, same project directory, and same model work fine. The conversation is permanently unrecoverable — retrying re-sends the identical history, so it can never succeed.

Failure signature (from the session JSONL):

• Each attempt: request is accepted, the model "thinks" for ~50s, a thinking block arrives in the stream (empty thinking text + signature — the normal encrypted-reasoning shape for this model), then the stream dies with a 500 before any text/tool_use block.
• Reproduced 4/4 times: first failure 07:00:16Z, then 07:11:50, 07:14:21, 07:19:26 (2026-06-11). The turn immediately before the first failure completed normally.
• Two other Claude Code sessions running simultaneously on the same model (claude-fable-5), same host, same settings/hooks: zero API errors. This rules out network, auth, host state, and global outage.

Transcript forensics

• 292-entry JSONL, ~658 KB, no images, no malformed lines.
• 25 thinking blocks in history, all empty-text-with-signature (consistent with healthy Fable 5 sessions).
• Anomaly: one thinking block's signature field is 66,356 chars — 6× larger than the maximum observed in any healthy session on this machine (~10K). It entered history ~10 minutes before failures began (a few successful turns in between), so it may be necessary-but-not-sufficient; failures began on the first message after an unusually long (11-minute) multi-tool turn.

Environment

• Claude Code 2.1.173, Linux (Arch, kernel 7.0.10)
• Model: claude-fable-5
• Session id: 12c08f3d-469a-46e5-b07c-31c5b66f60fb (in case server-side request logs can be correlated)

Why this deserves a look beyond the generic 500 reports

Most open 500 issues here are transient server blips. This one is deterministic per-conversation: some property of the accumulated history reproducibly kills the request server-side after thinking completes.

Client-side asks

1. Surface the API request-id in the error message so server-side correlation is possible from a bug report.
2. Detect the repeated-500-on-identical-history case and offer a recovery path (e.g., fork the session dropping the oldest thinking signatures, or a --strip-thinking resume mode). Right now the user's only option is abandoning the conversation; /compact presumably fails too since it sends the same poisoned payload.