Move a worktree thread (and its changes) to the current checkout

[EduardoDadalt]

Problem

T3 Code makes it easy to start work in a worktree, and agents can hand a thread from the
current checkout into a new worktree (t3_worktree_handoff). There is no way back.

When work started in a worktree should continue in the project's own folder (to run the
real dev environment, use a tool that is only set up there, or just stop juggling a
second checkout), today you have to do it by hand:

1. commit/stash whatever is in the project checkout,
2. detach or remove the worktree so its branch can be checked out elsewhere,
3. check the branch out in the project folder and carry the uncommitted changes over,
4. and the thread keeps pointing at the old worktree path, so it can't follow.

Step 4 has no manual workaround: the thread stays bound to the worktree.

Proposal

A thread action, Move to current checkout, available for idle threads that work in
a worktree (sidebar right-click menu and the chat header's thread menu on web/desktop).
It:

• checks out the worktree's branch in the project folder (detached commit if the
  worktree was detached), so commits made in the worktree come along;
• brings over the worktree's uncommitted changes — modifications, deletions, and new
  files — as ordinary unstaged edits;
• re-points the thread at the project checkout (worktreePath: null), so the next turn
  runs there;
• removes the worktree.

Files ignored by Git (.env, node_modules) are not moved, and the dialog says so.

Never overwrite local work

• If the project checkout has uncommitted changes, the move refuses unless the user
  picks Commit (with a message), Stash, or Discard in the dialog.
• The worktree's state is captured to a hidden ref (reusing the checkpoint capture)
  before anything changes, so a failure can't lose the work being moved.
• Changes are applied with git read-tree -m -u, which refuses to overwrite files that
  differ from what it expects.
• Every step rolls back the earlier ones if a later one fails (including the thread
  metadata update), leaving the worktree on its branch with its changes and the
  checkout on its original branch.
• Refused while the thread is running/queued, or when another thread still uses the
  same worktree.

Shape

• One server service method (git.moveThreadToLocalCheckout RPC), so the same
  capability could later be exposed as an MCP tool, the reverse of
  t3_worktree_handoff.
• Gated by an environment capability so app.t3.codes hides it against older servers.
• Proposed scope for a first PR: web + desktop only. Mobile and an MCP tool could follow
  if wanted.

I have a working implementation with tests against real Git repositories (full move,
dirty-checkout refusal, stash, rollback on failure) and would be happy to open a PR if
the direction and scope sound right.

Questions for maintainers

1. Is a "move back to current checkout" action something you want in T3 Code?
2. Should the worktree be removed after a successful move, or left (detached) for the
   existing worktree cleanup to handle?
3. Is offering Commit / Stash / Discard for a dirty checkout the right UX, or should the
   move simply refuse and let the user clean up first?
4. Web/desktop first, or should mobile and the MCP tool be part of the same change?