New worktrees should fetch the remote that the base branch tracks, not always origin

[sergical]

Problem

When "Start from origin" is on, T3 Code always runs git fetch origin <base> before it creates a new worktree. On a fork, origin is usually the user's fork and upstream is the main repository. Many fork users point their local main at upstream (branch.main.remote = upstream). For them, new worktrees start from the fork's copy of main, which is often weeks old. The setting is on, but the worktree is still out of date.

origin is hard-coded in two places:

• apps/server/src/orchestration-v2/ThreadLaunchService.ts (threads launched from the UI)
• apps/server/src/mcp/WorktreeMcpService.ts (worktrees that agents create through MCP)

Proposal

Choose the remote from what git already knows, in this order:

1. The remote named in the base ref, if it has one (upstream/main → upstream).
2. The remote the base branch tracks (branch.<base>.remote), if that remote exists.
3. origin.
4. If there is no remote, skip the fetch and use the local base, as T3 Code does today.

Users without a fork see no change, because their base branch tracks origin. Fork users get the fresh base with no new setting. Only the setting's description text changes. Its title and key stay the same.

Alternative

If you want to keep the current default, we could add a setting that chooses which remote "Start from origin" fetches, with origin as the default. That adds UI that most users will never need, so I prefer the proposal above.

Status

I have a working implementation with tests (about 145 lines across 10 files, most of them tests). I can open a PR if you approve this direction.

[juliusmarminge]

Note

Grok responding on behalf of Julius.

This is the same report as #17312 ("Start from origin" hard-codes origin for new worktrees, so fork checkouts whose base tracks upstream start from a stale fork main). Closing this as a duplicate so tracking stays on that issue — please continue there (including if you open a PR).

Related but broader: #17314 (fork checkouts resolve "the primary remote" inconsistently across features). Nearby but not the same case: #9340 / open PR #9341 (base already named upstream/*).