[FEATURE] Add "Fork into worktree" option to "Fork from here" in Claude Desktop (Code mode)

Preflight Checklist

• [x] I have searched existing requests and this specific feature has not been requested
• [x] This is a single feature request

Summary

In the Claude Desktop app (Code mode), the existing "Fork from here" action creates a new branch of the conversation but reuses the same working directory as the parent chat. Meanwhile, when opening a brand-new chat, the UI already offers a "Open in worktree" option that spins the session up inside a dedicated git worktree.

Please add the same "Fork into worktree" option to the "Fork from here" action so a forked conversation can also run against its own isolated worktree.

Problem Statement

Today, forking a conversation from a specific turn is great for exploring an alternative approach without losing the original thread — but because the fork shares the parent's working directory, any file edits the fork makes immediately conflict with edits the parent (or any other sibling fork) makes.

This forces users to choose between:

1. Forking the conversation and manually creating a worktree afterwards (breaks the "fork and try something different" flow; easy to forget and pollute the parent's working tree).
2. Starting a brand-new chat in a worktree (loses all the prior conversation context that motivated the fork in the first place).

The "Open in worktree" option already exists for new chats, so the primitive is there — it just is not wired into the "Fork from here" action.

Proposed Solution

When the user clicks "Fork from here" on any message in Claude Desktop (Code mode), expose a secondary toggle / sub-option:

• Fork in current worktree (today's behavior — default)
• Fork into new worktree (new — mirrors the "Open in worktree" option on new chats)

When "Fork into new worktree" is selected:

1. Create a new git worktree from the repo's current HEAD (or let the user pick a base branch, same UX as the new-chat flow).
2. Start the forked conversation rooted in that new worktree path, preserving the full message history up to the fork point.
3. Show the worktree path in the session header, the same way it is shown for worktree-based new chats.
4. On session end, follow the same cleanup UX that the new-chat worktree flow already uses (keep / delete prompt).

Why this matters

• Parallel exploration without conflicts. Users can fork a conversation to try an alternate refactor, architecture, or bug fix while the original thread keeps iterating in the main worktree — no file-system collision.
• Consistency with the new-chat flow. The "Open in worktree" affordance already exists for new chats. Extending the same capability to forks removes a surprising inconsistency in the UX.
• Safer A/B of approaches. Forking is most valuable exactly when you want to compare two paths. Today, the second path has to overwrite the first's files, which defeats the purpose.
• Low implementation cost. Both building blocks — forking a conversation and opening a chat in a worktree — already ship. This is a composition of the two, not a new subsystem.

Alternatives considered

• Manual git worktree add after forking. Works, but defeats the "one click to explore an alternative" goal of the fork action and is easy to forget.
• Always fork into a worktree. Too invasive — some users fork just to rewind context without needing a separate workspace.
• CLI-only flag. Does not help Desktop users, where the fork action lives as a UI button.

Additional context

The existing UX to reference is the "Open in worktree" option that appears on the new-chat dialog in Claude Desktop's Code mode. The requested behavior is to expose the same choice on the "Fork from here" affordance.