Consolidate IssueTracker gh calls into one GraphQL query

[dhilgaertner]

Closes #173.

Summary

• Collapse the per-refresh fan-out in IssueTracker.refresh() into a single aliased gh api graphql call that returns open assigned issues (with project status), viewer PRs (with checks/reviews/mergeable), recent closed issues, review-requested PRs, and the rateLimit block.
• Rewrite checkSessionPRs, fetchPRStatuses, autoCompleteFinishedSessions, and autoCompleteFinishedReviews as local index lookups over that payload — zero per-session gh calls. Delete checkPRMerged / checkIssueClosed.
• Add GitHubRateLimit to AppState, proactively skip polls when remaining < 50, parse 403 / Retry-After / X-RateLimit-Reset on failure to suspend until reset, and render a rateLimitWarning banner in SettingsView next to the existing scope-warning banner. Each refresh logs a summary (N gh calls in Xs, GraphQL R/L remaining, resets in Nm).

Steady-state cost: 1 gh call per refresh for a GitHub-only workspace (prior: 30–50).

Test plan

• make build — clean compile
• make test — 17/17 pass
• Run app with ~10 active sessions; verify the [IssueTracker] refresh: N gh calls … log line reports N == 2 in steady state (1 GitHub GraphQL + 1 per GitLab host)
• Ticket board, review board, and per-session PR status badges render identically to pre-change
• Merge a PR linked to an active session → the session auto-completes within one refresh, no extra gh pr view calls in the log
• Force remaining < 50 locally → rateLimitWarning banner shows in Settings, refresh is skipped until reset, banner clears on recovery
• Revoke read:project scope → existing scope banner still fires; refresh retries without projectItems so the rest of the data still renders

Out of scope (followups)

• Raising pollInterval / event-driven refresh
• Replacing gh CLI with a persistent GraphQL client
• IssueTracker unit tests (needs a shell/Process abstraction that doesn't exist yet)
• Moving the warning banner from Settings into TicketBoardView / ReviewBoardView

🤖 Generated with Claude Code

[dgershman]

Code & Security Review

Critical Issues

None found.

Security Review

Strengths:

• No secrets or credentials exposed in the codebase
• Rate-limit handling prevents runaway API usage; proactive threshold (remaining < 50) plus reactive 403/Retry-After parsing is a solid defense-in-depth pattern
• The retryWithoutProjectItems graceful degradation for INSUFFICIENT_SCOPES keeps the app functional even with reduced token scopes
• Shell commands use Process with explicit argument arrays — no shell expansion, so no command injection risk
• GraphQL query variables are passed via -F/-f flags, not interpolated into the query string (except the search queries which use safe @me / type:issue literals)

Concerns:

• parseResetAt uses .range(of:options:.regularExpression) and then .split(separator: ":") to extract the numeric value, which works but is slightly fragile — it relies on the matched string containing exactly one colon. Not a security issue, but a robustness nit (line 138–154)
• The closedSinceString() date formatter uses DateFormatter with a hardcoded format string and UTC timezone — correct, but worth a comment that this intentionally differs from the ISO8601DateFormatter used elsewhere

Code Quality

Positive:

• Massive API call reduction (30–50 → 1–2 per refresh) is a significant improvement
• Clean separation: ConsolidatedGitHubResponse + parsing functions are well-structured
• The ViewerPR struct captures all needed fields, enabling applySessionPRLinks, applyPRStatuses, and autoCompleteFinishedSessions to be pure local index lookups
• retryWithoutProjectItems via string replacement is pragmatic — the alternative (maintaining two query strings) would be worse
• Review request sorting (newest first) is a good UX touch
• logRefreshSummary provides useful observability for debugging

Minor items:

• applyPRStatuses at line 739: Dictionary(uniqueKeysWithValues:) will crash if two PRs share the same URL. This shouldn't happen in practice (GitHub URLs are unique per PR), but Dictionary(viewerPRs.map { ($0.url, $0) }, uniquingKeysWith: { a, _ in a }) would be safer
• applySessionPRLinks creates a new JSONStore() on every call (line 659). If JSONStore.init is cheap this is fine, but if it reads from disk on init it's worth caching
• autoCompleteFinishedSessions at line 824: same Dictionary(uniqueKeysWithValues:) pattern — same low-risk crash potential
• The viewer.pullRequests(first: 100, states: [OPEN, MERGED, CLOSED]) fetches all PR states including merged/closed. For users with many historical PRs, this could return stale data filling the 100-item limit. Consider whether first: 100 is sufficient or if filtering to [OPEN] + a separate recent-merged query would be more reliable for the auto-complete use case
• retryWithoutProjectItems uses String.replacingOccurrences to strip the projectItems block from the GraphQL query. This works but is sensitive to whitespace — if the query formatting changes, the replacement silently becomes a no-op. A comment warning about this coupling would help future maintainers

Summary Table

Priority	Issue
🟡 Yellow	Dictionary(uniqueKeysWithValues:) in applyPRStatuses / autoCompleteFinishedSessions could crash on duplicate keys (unlikely but defensive fix is trivial)
🟡 Yellow	viewer.pullRequests(first: 100) across all states may miss recent PRs for prolific contributors
🟢 Green	retryWithoutProjectItems string replacement is fragile to whitespace changes
🟢 Green	JSONStore() instantiated per call in applySessionPRLinks — verify init cost

Recommendation: Approve. This is a well-executed consolidation that dramatically reduces API calls from ~30–50 to 1–2 per refresh cycle. The rate-limit handling is thorough (proactive threshold + reactive 403 parsing + UI banner). The yellow items are low-probability edge cases worth addressing in a follow-up but not blocking.