Adoption Challenges: Repo/Branch/Worktree Experiences

The biggest challenge I've had transitioning to the Copilot App is the overall experience with repos/forks/branches/worktrees, respecting my personal preferences and existing setups therein.

I already have dozens of repos cloned with both upstream and fork remotes, and sometimes additional remotes as well. I already have some of those clones set up to use worktrees and some not, most with multiple branches active.

Should I try to add a project based on the local folder? The upstream repo? My fork? Something else?

When new sessions are started, it isn't clearly presented what effects that will have. Will a new worktree be set up within my folder structure or somewhere else? Will that branch have a remote tracking branch preconfigured? If so, which remote will it point to?

When starting a session from an existing PR on a repo that is on someone else's fork and iterating on it, the session ended up creating a new branch on origin rather than adding the PR author's fork as a remote and pushing to it.

When I start a new session from an existing branch/worktree, the app seems to always create a fresh worktree from that rather than letting me continue the work that was already there, and this has led to really confusing situations of what branch the work is landing on and what folder that branch is associated with--both with and without existing worktree setups.

## Summary
Overall, it's not clear how each of the project setup modes translates to how sessions will be set up within that project, how branches will be managed, how remotes will be configured, etc.

## Suggestions
To combat all of this, I highly recommend some additional first-run experience features. Instead of starting out by prompting the user to add projects, add a screen ahead of that to explain how each of these options results in the project being configured.

Then, as projects are added, present details of exactly how that project will be set up based on what was selected. Give the option of changing the folder on disk there, the branch naming convention, and other related details.

When a new session is being started for a project, make the same info also readily apparent.

With existing projects and sessions, add UI that allows me to VERY easily see for that project and session:
- What remotes are configured
- What branch the session is tied to
- What folder location that branch/worktree is mapped to

We should also allow a new session to be created from an existing branch (with or without a worktree). If worktrees are not yet configured, this could result in walking the user through that initializatsion for the session, explaining why the worktree approach is required. If it's already a worktree, let the session run from there without forking into a new branch/worktree.

---
| Field | Value |
| --- | --- |
| App version | 1.0.25 |
| OS | Windows 10.0.26200 |
| Theme | GitHub |
| Path | /chat |
| Tenure | Week 3 |

Start by mapping the project setup, project-addition, and new-session flows described in the issue, including existing branches and worktrees. Define how each flow exposes remotes, branches, folder locations, and worktree behavior; done means users can understand those effects and start a session from an existing branch without confusing duplication.

Written by the indexing model from the issue text.