Decouple sessions from worktrees: support multiple sessions per branch and worktrees from existing branches

### Feature summary

Decouple sessions from worktrees: support multiple sessions per branch and worktrees from existing branches

### What problem are you trying to solve?

Today, the Copilot coding agent in the GitHub app ties one session ↔ one worktree ↔ one new branch. This forces me to create many throwaway worktrees and branches just to explore ideas, brainstorm, or run quick parallel experiments. The model is too rigid for real-world workflows.

I often want to run parallel sessions related to the same work, but the right level of shared state (context, worktree, branch) varies a lot depending on the task:
- Same worktree, same branch, different chats: e.g., main session is actively coding a feature, and I want a separate chat for brainstorming or asking questions. I don't want to pollute the main session's context or create a new worktree/branch just to think out loud.
- Same branch, independent sessions making changes: e.g., two sessions working in the same area from different angles, sharing a branch so their work accumulates in one place.
- New worktree branched off another session's branch: starting a new, isolated session (inheriting context) from another session's branch (not just main), to explore a variant without disturbing the originating session.
- Forked session: duplicating an existing session's full context into a new session on the same branch/worktree to take the work in a different direction (supported in Copilot CLI, not in app).

Today none of this is available. This leads to many throwaway worktrees and branches, lost/polluted context, or having to fall back to the CLI.

### Proposed solution

Decouple sessions, worktrees, and branches. Requested capabilities:
1. Allow creating a worktree that checks out an existing branch instead of always creating a new branch.
2. Allow creating a worktree from any branch, including one created by another worktree session.
3. Support forking an existing session from the app (parity with Copilot CLI).
4. Support multiple sessions on the same worktree (same branch, multiple chats) for research or quick changes, without polluting the main session or requiring a new worktree.
5. Allow specifying the branch name when creating a worktree, rather than having it auto-generated (it should still be auto-generated by default if no name is specified).

Simple remains the default: one session per worktree, but advanced users can opt in to more complex patterns.

### Workflow impact

This would drastically improve developer productivity and flexibility for advanced users. It enables side-channel research chats, parallel experiments on a shared branch (user manages conflicts), and deeper investigation without context loss. Fewer throwaway worktrees/branches and less manual cleanup, and the app reaches feature parity with the Copilot CLI.

Enabling custom branch names when creating worktrees would also make it easier to organize, track, and refer to experiments or parallel work in the repository.

### Installation context

Affects all installs using Copilot coding agent for advanced workflows.

### Additional context

Example scenarios:

- Brainstorming alongside coding: main session is implementing a feature on branch feat/x; I spin up a second session on the same worktree just to discuss design tradeoffs—no commits, no new branch.
- Parallel experiments on a shared branch: two sessions work on the same branch (not separate branches), each making changes in unrelated areas (user manages non-conflict), so commits accumulate on one branch/PR. Today this isn't possible—multiple sessions always create new worktrees/branches, so I have to manually merge.
- Branching off a session's branch: session A created branch feat/x; I start session B in a new worktree checked out from feat/x, inheriting A's session context, to explore an isolated variant.
- Forking a session: I duplicate session A's full context to session A′ on the same branch/worktree and take it in a new direction.

The CLI already proves the more flexible model works. The app should reach parity.