[BUG] /resume produces immediate 400 tool use concurrency error on first message

Description

After using /resume to continue a previous conversation, the very first message sent triggers:

API Error: 400 due to tool use concurrency issues. Run /rewind to recover the conversation.

The error occurs immediately — no tool calls or compaction happened in the new session. The resumed conversation history is already corrupted from reconstruction.

Steps to Reproduce

1. Have a conversation with tool use (e.g., file reads, bash commands)
2. End the conversation
3. Start a new session and /resume the previous conversation
4. Send any message (e.g., "so")
5. Immediately get API Error: 400 due to tool use concurrency issues

Expected Behavior

The resumed conversation should have a valid message history and accept new messages.

Actual Behavior

The first message after /resume triggers a 400 error. /rewind does not fix it because the corruption is baked into the reconstructed history, not in a recent turn.

Additional Context

• Platform: Linux (Arch Linux 6.18.13)
• Interface: CLI (terminal)
• This is distinct from the compaction-related 400 error (#37452). The corruption happens during /resume history reconstruction, not during context compaction.
• /rewind cannot recover the conversation because the malformed tool_use/tool_result pairing exists in the resumed base history, not in a rewindable turn.

Screenshot

The previous session worked fine. After resuming and sending one message ("so"), the error appeared:

> so
⌐ API Error: 400 due to tool use concurrency issues. Run /rewind to recover the conversation.

Related Issues

• #37452 — Similar 400 error but caused by context compaction
• #21321 — Meta-issue for 400 concurrency errors
• #23093 — /resume breaking
• #9895 — Resume crashes