Server-side model upgrade (Opus 4.7→4.8) wedges in-flight sessions with `thinking blocks cannot be modified` 400

Summary

When the served model changes underneath an existing session (e.g. Opus 4.7 → 4.8), continuing that session fails fatally with:

API Error: 400 messages.N.content.M: `thinking` or `redacted_thinking` blocks in the latest assistant message cannot be modified. These blocks must remain as they were in the original response.

Thinking-block signatures are bound to the producing model, so 4.7-signed blocks already in the conversation history don't validate when the turn is continued on 4.8. There is no user-side fix-forward — only /clear (history is unrecoverable).

Expected behavior

On a model transition, the harness should reconcile prior thinking blocks (strip/drop the unvalidatable ones — they're internal reasoning state, not user content) rather than surface a fatal API error mid-turn. A server-side default model bump should not be able to corrupt a user's in-flight session.

Steps to reproduce / evidence

• Session started on Opus 4.7 (Claude Code v2.1.153), then continued after the served model moved to Opus 4.8.
• The failure is not content-dependent: the tool calls in flight (two innocuous URLs returning 404 and []) are coincidental. Every retry re-sends the same 4.7-signed assistant turn and dies at the same content.M.
• A fresh session born on 4.8 runs the identical tool calls with no error, which isolates the cause to pre-existing 4.7-signed thinking blocks in history rather than the request content.

Workarounds

• /clear to discard the corrupted history (prior reasoning lost).
• Disable extended thinking, which removes signed blocks from the request entirely.

Environment

• Claude Code v2.1.153
• Model transition: Opus 4.7 → Opus 4.8 (server-side)