Agent sessions: PR link never shows because the tracked branch goes stale (and gets cross-contaminated between sessions)

## Context

First of all: I love the new agent sessions UI — the worktree-per-session workflow is exactly what I want. But right now there are too many bugs around session ↔ PR association for it to be reliable, and I ended up patching internal state files by hand to get PR links to show up.

## Environment

- macOS (Darwin), VS Code stable
- GitHub Copilot Chat extension, agent sessions with one git worktree per session (`.worktrees/`)
- Sessions run Copilot CLI; branches are frequently renamed after session creation (e.g. `agents/shrill-hummingbird` → `kra-4625-...`) before the PR is opened

## Bug

The agents window resolves a session's pull request from the branch name recorded at session creation. That branch name is stored in several places and none of them stay in sync with the actual worktree branch:

1. `~/.copilot/session-state//vscode.metadata.json` → `worktreeProperties.branchName`
2. `~/.copilot/vscode.session.metadata.cache.json` (bulk cache)
3. `globalStorage/github.copilot-chat/session-store.db` → `sessions.branch` (SQLite)

Observed problems:

- **Stale branch after rename/checkout**: when the branch is renamed inside the worktree, none of the three stores are updated, so the PR lookup queries GitHub for a head branch that no longer exists → the PR link never appears in the sessions list.
- **External fixes get clobbered**: if I rewrite `branchName` on disk (with a newer `modified` timestamp), the extension periodically rewrites the metadata from its stale in-memory copy, undoing the fix. It takes many retries over several minutes for the value to stick.
- **Cross-session contamination in `session-store.db`**: the `sessions.branch` column contained the branch of a *different* session for several rows (e.g. 4 unrelated sessions all recorded with the same branch, others stuck on `master` even though their worktree was never on master). This looks like a shared/last-active-repository state being written to the wrong session row.
- Even with correct on-disk metadata, the extension does not re-run PR detection for existing sessions until a full window reload.

## Expected behavior

- The session's tracked branch should follow the worktree's actual `HEAD` branch (refresh on checkout/rename, or resolve it live from the worktree instead of a snapshot taken at session creation).
- PR detection should re-run whenever the tracked branch changes, without requiring a window reload.
- Each session's branch must be derived from **its own** worktree — one session's state should never overwrite another session's `branch` row.
- On-disk metadata edits with a newer `modified` timestamp should win over the in-memory copy (or the file should not be rewritten from stale memory at all).

## Steps to reproduce

1. Create an agent session that gets its own worktree; note the auto-generated branch (e.g. `agents/foo`).
2. Inside the worktree, rename the branch (`git branch -m kra-1234-foo`), push, and open a PR from `kra-1234-foo`.
3. Look at the agent sessions list: the PR is never linked to the session.
4. Inspect `session-store.db` → `sessions.branch` still holds `agents/foo` (or, worse, another session's branch).

Happy to provide the session-state files or a screen recording if useful. Thanks — again, really like where this UI is going, it just needs the branch/PR tracking to be trustworthy.