PR-status widget shows a newly-opened draft PR as "merged" (stale state from a previously-merged PR in the same session)

### Describe the bug

In the GitHub Copilot desktop app, the PR-status widget mislabels a newly-opened pull request as **"merged"** when it is actually open (and still a draft). The mislabel appears to be stale state carried over from a *previous* PR that the **same session** created and merged: after a session's first PR is merged, opening a second PR in that session renders the second PR as "merged" too.

Ground truth from the GitHub API for the affected PR at the time the app displayed it as merged:

```
state: OPEN isDraft: true mergedAt: null closed: false
```

…yet the app rendered it as merged.

### Affected version

1.0.69-2

### Steps to reproduce the behavior

1. In a project/worktree session, open a pull request (PR **A**) via the app's create-PR flow.
2. Merge PR **A** (state becomes MERGED on GitHub).
3. In the **same session**, open a second pull request (PR **B**) on a new branch, as a **draft**, via the create-PR flow.
4. Observe the PR-status view for PR **B**: it shows **"merged"**.
5. Confirm via `gh pr view --json state,isDraft,mergedAt` that PR **B** is actually `OPEN` / `isDraft: true` / `mergedAt: null`.

- Operating system: macOS (Darwin)
- CPU architecture: arm64
- Suspected cause: the session's "current PR" status is not reset when a second PR is created — the widget appears to retain the merged status of the first PR the session tracked, rather than re-fetching state for the new PR number.

Start by tracing the create-PR flow and how the session records the current PR status. Reproduce the sequence with PR A and draft PR B, then compare the widget with `gh pr view --json state,isDraft,mergedAt`. Done means a newly-created PR uses its own GitHub state and cannot retain the previous PR's merged status.

Written by the indexing model from the issue text.