Assistant text block dropped (UI + transcript) when followed by an interleaved thinking block before a tool call

Environment

• Claude Code VSCode extension (entrypoint: claude-vscode), reproduced on v2.1.235 and v2.1.237
• Windows 11 Pro (win32), model claude-fable-5

Summary
When an assistant response has the block sequence thinking → text → thinking → tool_use (interleaved thinking resuming briefly after user-visible prose, before a tool call), the text block is silently dropped from both the chat view and the session transcript (~/.claude/projects/<proj>/<session>.jsonl). Responses shaped thinking → text → tool_use render and persist correctly. The model's live context still contains the text (the assistant can quote its own dropped messages), so the loss happens in the client's streaming/persistence layer — but the content is unrecoverable after session resume and the user never sees it.

Symptoms

• In the chat view, the dropped message appears as an extra "Thought for 0s" entry: Thought for Ns / Thought for 0s / <ToolName>.
• In the transcript, two signed thinking entries (persisted ~1 ms apart) are followed directly by the tool_use entry; no text entry exists, and the text content appears nowhere in the file.

Reproduction

1. Get the assistant to write visible text and then think again before its next tool call (happens naturally and frequently when it summarizes findings before AskUserQuestion, Write, or Bash; in one session 10+ messages were lost, including recaps directly preceding AskUserQuestion calls — the user received questions with no visible context).
2. Grep the session .jsonl for a unique phrase from the on-screen-missing message: zero hits.
3. Controlled test: the assistant emitted a marker sentence ("TESTMARKER-B") deliberately followed by a thinking block and a Bash call. The persisted response shape was thinking → thinking → tool_use; the marker text was absent from the transcript (v2.1.237).

Impact
Data loss of assistant prose: user-facing explanations, question context, and status updates vanish without error. Particularly bad for AskUserQuestion/ExitPlanMode flows where the preceding message carries the decision context.