Deleted fork remote strands project sessions with no recovery path

## Summary

A Copilot app project can become unrecoverable when its local base clone still has `origin` pointing at a fork that has since been deleted, even though the app/project metadata points at the canonical upstream repository.

In my case, the `aspire` project is configured as `microsoft/aspire`, and current workflow is to use the official `upstream/main` / canonical repo directly. A previous session had created or used an `IEvangelist/aspire` fork. I later deleted that fork because I did not want it anymore.

After the fork was deleted, creating a new session/worktree for the `microsoft/aspire` project failed permanently because the app still tried to fetch from the deleted fork URL.

## Observed failure

When creating a new session/worktree, the app ran a fetch equivalent to:

```text
git ["-C", "C:\\Users\\dapine\\.copilot\\repos\\aspire", "-c", "credential.helper=", "fetch", "--progress", "https://x-access-token:[REDACTED]@github.com/IEvangelist/aspire.git", "+refs/heads/main:refs/remotes/origin/main"] failed: remote: Repository not found.
fatal: repository 'https://github.com/IEvangelist/aspire.git/' not found
```

The project record itself is for:

```text
microsoft/aspire
```

But the local clone still had stale Git remote config:

```text
origin https://github.com/IEvangelist/aspire.git
upstream https://github.com/microsoft/aspire.git
```

So worktree creation kept trusting the stale local `origin` URL instead of recovering from the app's configured project repo.

## Why this is a problem

This state is not recoverable from inside the app. Once the fork is deleted, every new session/worktree creation for that project can fail because `origin/main` points at a repository that no longer exists. The user is effectively stranded unless they know to manually edit the Git remote config outside the app.

The app should be able to recover because it already knows the canonical project repo is `microsoft/aspire`.

## Expected behavior

The app should detect this stale/deleted fork remote state and provide a recovery path, for example:

- If `origin` returns repository-not-found but the project metadata has a canonical GitHub repo, offer to reset `origin` to that repo.
- Prefer the configured project repo over stale local remote config when creating new worktrees.
- If both `origin` and `upstream` exist and `upstream` matches the configured project repo, use or promote that remote instead of failing permanently.
- Show an actionable recovery prompt in the UI rather than leaving the session creation stuck.

## Manual workaround

This fixes the local state manually:

```powershell
git -C "C:\Users\dapine\.copilot\repos\aspire" remote set-url origin https://github.com/microsoft/aspire.git
git -C "C:\Users\dapine\.copilot\repos\aspire" fetch origin main
```

But this should not require manual Git surgery, especially when the app already has the correct project repository configured.

## Environment

- App version: 1.0.55-0
- OS: Windows_NT
- Project: `microsoft/aspire`