[Bug]: Launching many threads into new worktrees at once fails most of them #17198

Before submitting

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

Area

apps/server

Steps to reproduce

1. In a project backed by a Git repo with an origin remote, start 10–20 threads at about the same time, each in a new worktree from the same base branch (for example from mobile, or with an agent calling t3_thread_launch / create_threads). Turning on "start from origin" makes it worse.
2. Optionally give several of them the same requested branch name.
3. Watch workspace preparation.

Expected behavior

Every thread gets its own worktree and starts. If a thread does fail, Retry recovers it.

Actual behavior

Only about 30% of the threads start. The rest stop at "Workspace preparation failed during provision worktree" with one of these errors:

• GitVcsDriver.fetchRemote: "Git could not update a local reference. Another Git operation or a stale lock may be blocking the fetch". Concurrent git fetch runs of the same base ref race for its ref lock.
• GitVcsDriver.createWorktree: git worktree add failed (branch_already_exists). Concurrent launches collide on a branch or path name, and Git can also report the losing atomic ref claim as cannot lock ref 'refs/heads/…': reference already exists.
• Writes to the shared .git/config (the gh-merge-base key written after checkout, and the background branch rename) fail on Git's config lock.

Retry hits the same collision again, so the only recovery is to delete each failed thread and launch it again.

Impact

Major degradation or frequent failure

Version or commit

nightly 0.0.46-nightly.20261006; reproduced on main @ a4c9494

Environment

macOS, Git 2.54, desktop app hosting the server; Claude and Codex providers (the failures are provider-independent)

Workaround

Launch threads one at a time, or delete each failed thread and launch it again.

Proposed fix: #17197