Rewind in Desktop breaks for messages that originated in Claude Code CLI (/desktop)

Bug

After using /desktop to bring a CLI session into Claude Desktop, rewinding to a message that was originally sent from the CLI fails. Sending a new message after the rewind produces:

No message found with message.uuid of: 67ddf594-1c16-4705-82df-b97e4073f64d

Rewind works correctly for messages sent natively within Desktop. It only breaks when the rewind target is a message that originated in the CLI terminal.

Steps to Reproduce

1. Start a session in Claude Code CLI (terminal): claude
2. Send 3–4 messages with tool use (file edits, bash commands, etc.)
3. Run /desktop to open the session in Claude Desktop
4. Send 2–3 more messages natively in Desktop
5. Use Rewind and select a message from step 2 (a CLI-origin message)
6. Try to send a new message
7. Error: No message found with message.uuid of: <uuid>

After restarting Desktop:

• The rewound messages reappear (rewind is undone)
• The session works again, but you're back to where you started

Expected Behavior

Rewind should work the same regardless of whether the target message originated in CLI or Desktop. After rewinding, the next message should succeed.

Actual Behavior

Two failures:

1. Immediate: Client sends a stale parent_message_uuid that the server already deleted during rewind → API 404
2. On restart: The CLI's local JSONL (which still has all messages) re-syncs via the bridge, undoing the rewind entirely

Analysis

The bridge between CLI and Desktop syncs messages from the local JSONL to a server-side conversation. Each synced message gets a server-assigned message.uuid.

On rewind:

• Server deletes messages after the rewind point ✓
• Client should update its tracked parent UUID to the rewind point's UUID ✗ (stale reference kept)
• Local JSONL should be truncated to match ✗ (untouched, so restart re-syncs everything back)
• Bridge state (processedMessageUuids) should be updated ✗

For Desktop-native messages, the server is the sole source of truth, so rewind works cleanly. The bug is specific to the dual-source-of-truth situation when CLI JSONL and server state diverge after rewind.

Suggested Fix

After rewind to a CLI-origin message:

1. Update the client's parent message reference to the rewind checkpoint UUID
2. Truncate the local JSONL to the rewind point (prevents restart from undoing the rewind)
3. Update bridge state to clear synced message references past the rewind point

Environment

• Claude Desktop v1.2773.0.0 (MSIX, Windows 11 ARM64)
• Claude Code CLI (latest)
• Workflow: CLI session → /desktop → rewind