[Bug]: A message to a thread whose worktree directory is gone starts no run and reports nothing; the automatic re-create fails with branch_checked_out_in_worktree; git and PR polling continue against the missing directory #21374

Before submitting

• I searched existing issues and did not find a duplicate. [Bug]: Deleting a thread's worktree while its session is "running" permanently wedges the thread (archive blocked, reaper never clears it) #4723 (closed) was the V1 wedge after deleting a worktree. This is the V2 behaviour.
• I included enough detail to reproduce or investigate the problem.

Area

apps/server

Steps to reproduce

1. Create a thread in a T3-managed worktree and let a turn complete.
2. Remove the worktree directory outside T3 (git worktree remove <path>; a cleanup job did this for us) and, to hit the second failure, check the same branch out in another worktree.
3. Dispatch a message to the thread.

Expected behavior

• The dispatch returns an error the caller can see (worktree_missing), and the thread shows it.
• The automatic re-create handles a branch that is checked out elsewhere (detach, a new branch name, or a clear refusal), instead of failing silently.
• Background git/PR polling stops for a thread whose worktree is gone.

Actual behavior

• 2026-09-19 (0.0.4x): thread.turn.start answered OK and started no run. Eight wakes were lost between 03:40Z and 04:35Z before anyone noticed.
• 2819: the server now tries to repair: provider turn start recreating missing worktree 17 times between 2026-10-07 and 10-17, and git worktree add failed (branch_checked_out_in_worktree) 5 times (2026-10-13) when the branch lived in another worktree. Those turns still never started, and nothing told the sender.
• Checkpoints keep running against the missing path: diffCheckpoints: git diff (/data/t3-worktrees/.../todo-16044) exited with 128 - fatal: cannot change to ....
• PR polling keeps running against it too: GitManager.branchPullRequest.remotes ... (not_a_repository) 13,429 journal lines in 11 days (see [Bug]: Background PR sync and settlement send 500–1,100 GitHub GraphQL calls an hour on a ~50-thread server and keep polling threads whose worktree is gone (18,787 failed lookups and 482,099 "settlement skipped" lines in 11 days) #21372).

Impact

Major degradation or frequent failure

Version or commit

0.0.46-nightly.20261008.2819 (and 0.0.4x for the silent OK). Our local patches do not touch worktree handling.

Environment

Linux (Ubuntu, kernel 7.0.0-38-generic), compiled @t3code/t3-linux-x64 binary (Node.js v26.8.2 in crash traces), t3 serve --host 127.0.0.1 --port 3773 --base-dir ~/.t3 as a systemd --user service, headless; Tailscale serve in front; clients: macOS desktop app, iOS app, web. 40–50 live threads at a time over 8 Claude Code instances (claudeAgent), 3 Codex instances and ACP providers (Grok CLI, OpenCode with GLM). ~16,900 threads in statev2.sqlite (40.4 GB). Threads are created, woken and stopped by our own tooling over the /ws RPC (orchestration.dispatchCommand), not by a human in the UI.

Running build: 0.0.46-nightly.20261008.2819 with two local server patches (GitHub PR-sync cadence, Grok multi-task wait). Each draft says whether the patch touches the reported area.

Logs or stack traces

provider turn start recreating missing worktree { threadId: '<id>', worktreePath: '/data/t3-worktrees/<repo>/<branch>' }
git worktree add failed (branch_checked_out_in_worktree)
diffCheckpoints: git diff (/data/t3-worktrees/ProcessFrontend/todo-16044) exited with 128 - fatal: cannot change to '/data/t3-worktrees/ProcessFrontend/todo-16044': No such file or directory

Workaround

Before every dispatch our tooling stats the thread's worktreePath and refuses with its own NO-TURN cause=worktree-missing; a watcher then creates a new thread in a fresh worktree. Our cleanup job also refuses to remove a worktree that still has a live thread.