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

[tom-un]

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 <B> --json state,isDraft,mergedAt that PR B is actually OPEN / isDraft: true / mergedAt: null.

Observed in practice: a session created PR #4350 (later merged), then created draft PR #4428 in the same session — #4428 displayed as merged despite being an open draft.

Expected behavior

The PR-status view should reflect the current PR's real state from GitHub (open / draft / merged / closed). Creating a new PR in a session should reset the tracked PR status; a freshly-opened draft PR must never render as "merged."

Additional context

• 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.