[BUG] Desktop 2.7032.0: PR monitor loops on GraphQL NOT_FOUND (~5000/h), falls back to REST and exhausts both GitHub rate limits

Summary

After the desktop app updated from 2.110.1 to 2.7032.0 (Linux, Claude Code 2.1.280), the PR monitor (GitHubPrManager / GhRestClient) sends a continuous stream of GraphQL queries that come back NOT_FOUND: about 5,000 per hour. That exhausts the user's GraphQL budget. The app then falls back to REST ("rows GraphQL read in the last 5 min are read over REST while it has headroom"), which exhausts the REST core limit (5,000/h) too. As a result, every gh call from every session, and from the user's own terminal, fails with API rate limit exceeded for hours.

Evidence (from ~/.config/Claude/logs/main*.log)

Count of [warn] [GhRestClient] GraphQL errors: count=N types=NOT_FOUND(N) lines:

| Log window | App version | NOT_FOUND lines |
|---|---|---|
| Aug 12 – Aug 28 | 1.x | 86 |
| Aug 28 – Sep 9 | 1.x | 121 |
| Sep 9 – Sep 19 | 1.x / 2.110.1 | 50 |
| Sep 27 18:06 (update) – Sep 28 07:00 | 2.7032.0 | ~64,000 (4,000–6,300 in every hour) |

Per hour after the update (local time):

2026-09-27 18  notfound=5024
2026-09-27 19  notfound=5007  failed=115
2026-09-27 20  notfound=4972
...
2026-09-28 05  notfound=6338
2026-09-28 06  notfound=5013

• The storm begins in the same minute as [updater] Version changed since last launch: 2.110.1 → 2.7032.0.
• GraphQL budget low (88 left) fires about 10 times. After each one, [GitHubPrManager] Failed to get PR state by number: Error shows up in bursts of up to 42 per minute once REST is exhausted too.
• gh api rate_limit reports core: used 5000/5000, then graphql exhausted as well: API rate limit already exceeded for user ID ….
• The user's agent sessions account for an order of magnitude fewer requests. The drain continues while no session is running any gh command.

Second, related issue: merged PRs are polled indefinitely

LocalSessions.getPrChecks keeps polling PRs that are already merged. Several merged PRs were polled 300–386 times each in about 13 hours. Most of this came from two long-lived sessions with 14–19 PRs bound. This looks related to #66763, where PR chips never retire after merge.

Suspected trigger

Each failing GraphQL batch carries 1–3 PR references that never resolve, and the monitor keeps retrying them rather than dropping them. My guess is PRs bound to sessions that belong to a different repository or GitHub account than the one being queried, for example a session that pushed to a second repo. I have not confirmed this; the log does not say which node is NOT_FOUND.

Expected

• A PR reference that returns NOT_FOUND should be unbound or backed off, not re-queried every second.
• The REST fallback should not spend the user's whole REST quota when GraphQL is low.
• Merged or closed PRs should stop being polled.
• It would help to log which PR/repo returned NOT_FOUND.

Environment

• Linux (apt install), desktop app 2.7032.0, Claude Code 2.1.280
• About 50 local sessions/worktrees on one repo, ~29 distinct PRs bound; several sessions have 4–19 PRs bound
• gh authenticated with two accounts (one active)