Cached prState in list_sessions goes stale after a PR merges

Description

A session's list_sessions entry reported prState: "OPEN" for PR #375 in a project, but the PR was actually MERGED on GitHub at the time (confirmed live via gh pr view 375 --json state, which returned "state":"MERGED").

This looks like the same class of issue as #95723 (stale worktreePath/worktreeName after a worktree is removed) — session-list metadata that isn't refreshed/invalidated when the underlying GitHub state changes. Filing separately per request in that issue's thread, since the fix path may differ even if the root cause (a cache that doesn't get invalidated on external state changes) turns out to be shared.

Impact

Low severity — no data loss, just a misleading status shown in list_sessions/get_session. Could cause confusion (e.g. thinking a PR still needs review/merging when it's already landed) or make automated tooling built on top of this data draw the wrong conclusion.

Repro sketch

1. Have a session with an open PR tracked in its metadata (prNumber set).
2. Merge that PR on GitHub, outside of any action taken through this session.
3. Call list_sessions (or get_session) for that session later — prState still reads "OPEN" instead of "MERGED".

Related

• #95723 — same class of staleness, for worktreePath/worktreeName after worktree removal.

Start at the list_sessions and get_session entry points and trace how prState is read after a PR is merged externally. Reproduce with gh pr view 375 --json state, then verify that session metadata reports MERGED rather than retaining OPEN after the GitHub state changes.