[P2] Add retry/backoff on GitHub API fetch calls for transient 429/5xx #795

Ask: Add shared retry-with-backoff to the GitHub API fetch helpers so transient 429 and 5xx responses are retried instead of surfaced as hard errors.
Expected files: src/lib/github-auth.ts, src/lib/github-issues.ts, src/lib/github-ci.ts, src/lib/github-prs.ts

Problem: Every GitHub API call in the app is a single fetch that throws immediately on any non-2xx. When Dispatch hits GitHub primary/secondary rate limits (429) or a transient 5xx, the whole sync, pr-fix, CI-polling, or reconcile operation fails outright instead of retrying. During bursts (large sync runs make dozens of sequential calls) these transient failures are real and cause sporadic run errors that a simple backoff would absorb.

Evidence: All helpers in src/lib/github-ci.ts (lines 14-19, 67-73, 151-158, etc.), src/lib/github-issues.ts (lines 22-26, 95-103, 147-155, etc.), and src/lib/github-auth.ts fetchPaginated do a bare fetch then throw new Error("... ${response.status} ...") with no 429/503 handling and no Retry-After/x-ratelimit-reset awareness. grep -n "!response.ok" across those files shows the pattern is unreplicated per-endpoint.

Acceptance: A shared helper (e.g. src/lib/github-auth.ts) retries idempotent reads at least 2-3 times with exponential backoff, honoring Retry-After/x-ratelimit-reset on 429, and the existing fetch helpers call it. A unit test proves a mocked 429/503 is retried and eventually succeeds or raises after exhausting retries.