[Bug]: unsettled thread on a down machine blocks opening new threads until the machine serves again

[Kamkmgamer]

Summary

When one machine is down (or not serving) and the user opens a project that the down machine was last working on, and the project's latest turn is unsettled, the app automatically opens the unsettled thread and the user is stuck with it: there is no way to settle it (the owning machine is unreachable) and no way to open a new thread or pick another machine to run in. Everything works again only after running npx t3 serve on the down machine, at which point the user can finally open a new thread.

Repro

1. Machine A and machine B are both connected (e.g. via T3 Connect) and sharing projects.
2. Machine A works on project P and leaves its latest turn unsettled (e.g. the machine is shut down mid-turn).
3. From the client, open project P (or land on it).
4. Observed: the app opens the unsettled thread owned by the down machine A. Starting a new thread does not work and the user cannot move past the unsettled state.
5. Run npx t3 serve on machine A.
6. Now the project works again and the user can open a new thread.

Expected

When the machine that owns the unsettled thread is unreachable, the app should not block on that thread. Instead it should either:

• automatically open the unsettled thread so the user can settle it, or
• let the user choose another machine (environment) to run in when the project is available on another one.

Notes from code exploration

• A thread's latest turn is unsettled while its session leaves "running" (thread.unsettled events; settledTurnStateForSessionStatus in apps/server/src/orchestration/projector.ts settles a still-running turn only once the session's status leaves running).
• isLatestTurnSettled in apps/web/src/session-logic.ts treats the latest turn as unsettled while the session is running or the turn has no completedAt.
• Projects and threads are environment-scoped (scopeProjectRef / scopeThreadRef in packages/client-runtime), so an unsettled turn's session lives on the machine that was running it; while that machine is down, its session status cannot transition to settle the turn, which likely leaves the new-thread/draft flow stuck until the machine is reachable again.

[maslinedwin]

Opened #7195 for this.

When the machine that owns an unsettled latest turn is down, opening the project no longer traps you on that thread. The client lands on a new draft instead, skips the t3.json read that was hanging New Thread, and retargets the draft to another connected environment when the same project is available there.

The reachable-environment path is unchanged: an unsettled latest turn still opens so it can be settled. The remote turn is not fake-settled.