[BUG] Claude Code desktop auto-fix monitoring only subscribes to the first PR created in a session — later same-session PRs (visible in UI) get no review-comment/CI events

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported
• [x] This is a single bug report
• [x] I am using the latest version

What's Wrong?

In a single Claude Code desktop app session that opens multiple PRs on different branches in the same repo, the "auto-fix pull requests" monitoring subscribes only to the first PR created in the session. Reviewer comments and CI-failure events on the subsequent PRs are never delivered into the session, so Claude never sees or responds to review feedback on them.

This is distinct from #58166 (panel hides subsequent same-repo PRs): in my case all PRs are fully visible in the UI. The failure is purely in the event/monitoring subscription, not visibility.

It appears to be the monitoring-path manifestation of the root cause in #46625 — a session_id → pr_number mapping set at the first create_pull_request and never re-resolved. #46625 reports the "View PR" button sticking to the first PR; this is the same root cause hitting the auto-fix monitoring subscription.

What Should Happen?

Monitoring should subscribe to every PR the session creates (or at least every open one), re-resolving on each create_pull_request, so review comments and CI events on all of them surface — not just the first.

Steps to Reproduce

1. In the desktop app, start a session; have it create PR #N on branch feature-a.
2. In the same session, create PR #N+1 on feature-b (optionally #N+2 on feature-c) — a stacked-PR workflow. All open and visible in the UI.
3. As a reviewer, leave inline review comments on #N+1 / #N+2.
4. Actual: review-comment/CI events arrive for #N only; #N+1/#N+2 surface nothing and their comments sit unanswered. Expected: events for all session-created PRs.

(Reproduced with a 4-PR stack to one repo from one desktop session: only the first PR's review activity surfaced; the other three got none despite being open and visible.)

Notes

• Different branch names, no reuse, no force-push → distinct from the branch-name-cache cluster (#11161 / #30757 / #34042 / #15313).
• Same root cause as #46625 (auto-closed inactive, unfixed). TUI got a partial fix in #24834 ("only show open PRs").
• Observed on the desktop app. CLI template fields N/A.