feat(desktop): background PR status polling with priority tiers

[huntharo]

Summary

Keep every open project's pull-request status reasonably fresh, instead of refreshing only the selected/hovered thread. Before this, the sole recurring PR refresh was a renderer interval scoped to the selected thread, so the other 20–30 open projects showed stale chips ("a snapshot from the last time I moused over that PR 17 hours ago") — CI pass/fail, merges, and new merge conflicts on unfocused projects were invisible until interacted with.

A main-process poller now fetches many PRs across disparate repos in one aliased GraphQL request (in-process @octokit/graphql, token minted via gh auth token) on an attention-weighted cadence. One request of ~40 PRs across arbitrary repos costs ~1 rate-limit point (GraphQL's per-request floor), which is what makes minute-level polling of many projects affordable. The gh CLI can't do this — it's one subprocess per branch.

The change reuses PwrAgent's existing PrSummary model, sqlite caches, prStatusRegistry, PrStatusTokenBucket, terminal short-circuit, and the pullRequest/status/updated push bus — it adds coverage/cadence/transport, not a parallel data model.

Built in four phases:

• Phase 0 — github-graphql-client.ts: batched aliased query (owner/name/number passed as GraphQL variables, injection-safe), hand-rolled backoff honoring retry-after / x-ratelimit-reset / 5xx (deliberately avoids the octokit retry/throttling plugins, which drag in bottleneck), and partial-data salvage so one dead repo can't blank a batch. Derivations extracted to pr-derivations.ts so the gh and GraphQL transports can't drift; github-pr-fetcher.ts re-exports them so existing imports/tests are unchanged.
• Phase 1 — pr-polling-scheduler.ts: Focused (60s) / Warm (150s) / Cold (300s) tiers, round-robin by oldest-polled, terminal-PR drop, ×4 cadence stretch when the window is hidden. One token-bucket slot per request (not per PR). Fully dependency-injected — holds no AppServerService reference, so it's unit-testable without booting the app.
• Phase 2 — pollingFocus IPC: the renderer tells main which thread is selected (main has no other way to know — selection is renderer route state) so its PRs land on the fast tier.
• Phase 3 — pr-transitions.ts: a typed PrStatusTransition emitted from the single diff chokepoint (rememberPrStatuses, covering both the poller and on-demand refreshes) whenever checkState / lifecycleState / mergeState / reviewState / title flips, plus an onPrStatusTransition() subscriber seam. This is the webhook-ready hook for a future "CI failed → start a turn" ingestor. Logs today; no turn-starting, no thread events in this PR.
• Phase 4 — pr-discovery.ts: a slow branch-lookup rotation across all open threads to surface newly-opened PRs on unfocused projects, reusing the existing branch-based attach/cache/coalesce path. Restores the periodic cross-repo refresh that was lost.

Verification

• Full workspace suite: 4657/4657 tests, 365/365 files on the final run.
• 73 new unit tests across 4 suites: github-graphql-client, pr-polling-scheduler, pr-transitions, pr-discovery.
• Typecheck, ESLint (0 errors), lint:boundaries (clean, no octokit across the renderer/leaf boundary), and the Electron main-process build all pass.
• Live GitHub API check: ran the real client against the operator's gh token over 4 PRs spanning 3 unrelated orgs — HTTP requests to GitHub: 1, 4 PRs returned. Querying sindresorhus/p-map#88 correctly resolved identity to hong4rc/p-map#88, validating the fork-PR base-vs-head handling.

Notes

Three decisions a reviewer would otherwise have to reverse-engineer:

• Query by base repo, identify by head repo. A PR number belongs to the repo it was opened against (base), but PrSummary.org/repo (and the status key) track the head repo, matching what gh writes. For fork PRs these differ, so the client parses the base ref from the PR URL to query and reads headRepository* from the response to build identity. Getting this wrong would have silently duplicated every fork PR.
• Phase 4 uses a branch-lookup rotation, not a REST since crawl (a deviation from the plan). PwrAgent attaches PRs to threads by branch, so a "list PRs updated since T" crawl finds PRs with nowhere to attach. The branch lookup asks the question that maps to the UI and reuses the entire existing attach path — no new dependency, no schema migration, no git-remote parsing. A since-crawl remains the right tool only for thread-independent discovery (e.g. an all-org dashboard), noted in the plan.
• The renderer's 60s selected-thread interval was kept, not folded in. It re-runs a branch lookup, which is the only thing that discovers a PR newly opened on the selected branch — the poller only refreshes PRs it already knows by number.
• Build warning (benign): Rollup notes it can't code-split the lazily-imported gh-discovery / settings-singleton because other modules static-import them. The lazy import is kept deliberately — it's what lets the GraphQL client load under plain-node vitest without dragging in Electron.

Design docs: docs/brainstorms/2026-07-13-pr-status-polling-and-ci-events-requirements.md, docs/plans/2026-07-13-001-feat-pr-status-polling-plan.md.

🤖 Generated with Claude Code