[Bug]: Cursor provider responses disappear after assistant message id collision

[quick007]

Before submitting

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.

Area

apps/web

Steps to reproduce

1. Use T3 Code desktop with the Cursor provider.
2. Continue a Cursor-backed thread for many turns.
3. Send short follow-up prompts after prior assistant responses.
4. Observe that the provider logs / event store contain a new assistant response, but the UI/projection appears to show stale or missing assistant output.

Expected behavior

Each assistant response/turn should project into a unique message row and appear in the thread, even if Cursor ACP segment IDs are reused within the same provider session.

Actual behavior

The provider responds, and orchestration_events contains the missing assistant responses, but projection_turns.assistant_message_id reuses older assistant message IDs. Since projection_thread_messages.message_id is the primary key, later Cursor ACP responses with reused segment IDs appear to collide with older projected assistant messages. The UI then appears stuck or unable to show new useful assistant messages after a while.

It does seem like #871 and #882 might be related to this issue, but it seems like the thread IDs are colliding within the same session whereas that is cross-session collisions.

Impact

Blocks work completely

Version or commit

0.0.21

Environment

Windows 11, T3 Code desktop, Cursor provider, model gpt-5.5

Logs or stack traces

Local DB: ~/.t3/userdata/state.sqlite
Provider logs: ~/.t3/userdata/logs/provider/

Observed duplicate assistant message IDs across different turns:

Thread <thread-a>:
- assistant:assistant:<cursor-session-a>:segment:4 used by 3 turns
- assistant:assistant:<cursor-session-a>:segment:3 used by 3 turns
- assistant:assistant:<cursor-session-a>:segment:6 used by 2 turns

Latest prompt `please answer?` has a response in orchestration_events:
"Yes. **We’re good to move on to the next stage.** ..."
But projection points to an older segment:4 assistant row from much earlier.

Thread <thread-b>:
- assistant:assistant:<cursor-session-b>:segment:8 used by 2 turns
- assistant:assistant:<cursor-session-b>:segment:7 used by 2 turns
- assistant:assistant:<cursor-session-b>:segment:4 used by 2 turns
- assistant:assistant:<cursor-session-b>:segment:3 used by 2 turns

Latest prompt `you keep on stopping randomly. what's going on?` has a response in orchestration_events:
"Sorry. Two things happened: ..."
But projection reuses an older segment:8 assistant row.

Suspected cause: Cursor ACP segment IDs may not be globally unique across turns, but T3 Code appears to use them directly as stable projection_thread_messages.message_id values. Projection likely needs to include the T3 turn ID or another nonce in the message ID.

Related server-child.log notes:
- repeated `Cursor ACP capability probe failed` TimeoutError warnings around 14:34
- one affected session later became `stopped` via graceful session exit

Screenshots, recordings, or supporting files

No response

Workaround

No response

[quick007]

I can also submit a fix for this, but there's a chance #882 will, and if it doesn't then it's easier to build off that base