fix: pr-bug-scan validated finding from #6330

[buf0-bot]

Automated fix-PR from pr-bug-scan for parent #6330.

Fixer status: FIXED_WITH_CODE_PROOF
Summary: Added MAX_ISSUE_TIMELINE_PAGES=20 backstop to getIssueTimelineItems loop, bounding the unbounded sequential gh pagination on bot-noisy issues.
Blocked proof link: src/main/github/work-item-details.ts:291 — the pagination loop, which previously only stopped on items.length<MAX_ISSUE_TIMELINE_ITEMS (line 291, counting mapped items only) or a short page (line 316), now also stops at page<=MAX_ISSUE_TIMELINE_PAGES, so unsupported-heavy timelines can no longer walk the full timeline one gh subprocess per 100 raw events.
Typecheck: skipped

Proof (from validator)

• C1 — proof_type: code_analysis
  • trigger: Open the issue details drawer for an issue whose timeline has hundreds/thousands of unsupported events and fewer than 300 supported (assigned/closed/cross-referenced/etc.) activities.
  • observable: Drawer/Activity tab stalls for many seconds while issuing ceil(totalTimelineEvents/100) sequential gh subprocesses; one gh slot is occupied throughout, degrading concurrent gh-dependent UI.
  • path:
    • src/main/github/work-item-details.ts:989 getWorkItemDetails calls await acquire() once for the whole issue detail fetch
    • src/main/github/work-item-details.ts:399 getIssueDetailsViaGraphQL awaits getIssueTimelineItems while still holding that single semaphore slot
    • src/main/github/work-item-details.ts:291 loop condition items.length < MAX_ISSUE_TIMELINE_ITEMS counts only mapped/supported items (pushed at the inner loop), so a full page of unsupported events leaves items.length unchanged
    • src/main/github/work-item-details.ts:316 the only other stop is pageEvents.length < GITHUB_REST_PAGE_SIZE (a short, i.e. last, page); there is no max-page constant
    • src/main/github/gh-utils.ts:33 MAX_CONCURRENT=4 — the held slot is 1 of 4 for the entire sequential pagination run
• C2 — proof_type: code_analysis
  • trigger: Open an issue drawer (initial details fetch in flight) and optimistically close/reopen the issue before that fetch resolves.
  • observable: The state badge/edit control flips from the optimistic 'closed' back to 'open' (or vice versa) until the post-success invalidation triggers a fresh fetch.
  • path:
    • src/renderer/src/components/GitHubItemDialog.tsx:5247 handleStateChange.onOptimistic calls onStateChange(newState) (wired to setLocalState at 7120/7166), setting localState='closed'
    • src/renderer/src/components/GitHubItemDialog.tsx:6491 resolvedWorkItemState = details?.item.state ?? workItemState — prefers the detail payload's state
    • src/main/github/client.ts:821 details.item.state originates from getWorkItem's live gh api repos/.../issues/N read at fetch-launch time (state='open' when the drawer opened)
    • src/renderer/src/components/GitHubItemDialog.tsx:6571 the in-flight fetch resolves and writes its (now-stale 'open') result via touchWorkItemDetailsCache; the optimistic path never bumped workItemDetailsCacheGeneration (only invalidate at 1426/1449 does), so the stale write is not blocked
    • src/renderer/src/components/GitHubItemDialog.tsx:6495 the effect re-fires because resolvedWorkItemState changed back to 'open' and calls setLocalState('open'), reverting the badge

---

Generated by pr-bug-scan (proof-machine architecture). Human approval required before merge.