[Feature]: Let new-worktree threads attach to an existing branch instead of always forking a new one

[adibsaad]

Before submitting

• I searched existing issues and did not find a duplicate.
• I am describing a concrete problem or use case, not just a vague idea.

Area

apps/web composer / thread bootstrap (apps/server orchestration)

Problem or use case

I run agents on a remote server environment; they work on a branch and push when done. To verify locally, I want my laptop's T3 to create a local worktree that checks out that exact branch.

Today, the workspace selector's "New worktree" mode only forks: the branch I pick is used as a base, and T3 always mints a fresh temp branch (buildTemporaryWorktreeBranchName) and runs git worktree add -b t3/<hex> <path> <picked>. There is no way to say "give me a worktree on this branch as-is" — I end up on a new branch, which breaks the verify→instruct loop: my local verification is not on the same ref the server agent is iterating on.

Proposed solution

When the selected branch already resolves to a real branch (local, or remote-only like origin/foo → derive the local name) and is not checked out in another worktree, attach the new worktree to it (git worktree add <path> <branch>) instead of forking a temp branch. Branches that don't exist or are already checked out (e.g. main in the primary checkout) keep today's fork behavior.

Note the server primitive already supports this: VcsCreateWorktreeInput.newRefName is optional, and GitVcsDriverCore.createWorktree runs plain git worktree add <path> <refName> when it's omitted — the composer/bootstrap path just never uses that form (prepareWorktree.branch is always set). The change is contained to the client bootstrap: omit prepareWorktree.branch when attaching and pass the existing branch through.

Details worth covering

• Remote-only branches need the origin/foo → foo derivation (helper already exists in @t3tools/shared/git).
• Skip the startFromOrigin base-fetch path and gh-merge-base config when attaching (no new branch is created).
• The temp-branch rename reactor should be a no-op for attached branches (isTemporaryWorktreeBranch won't match) — worth a test.
• Edge cases: branch deleted between pick and send, branch checked out in a third worktree, fork remotes.
• Mobile recently gained "start a new thread on an existing branch" (feat(mobile): start a new thread on an existing branch #10359) — semantics should agree across clients.

[juliusmarminge]

Duplicate of #11099 (same report filed ~9s earlier).

[juliusmarminge]

Closing as duplicate of #11099.