test(miner-manage): regression coverage for the CI/gate polling backoff edge cases

[JSONbored]

test/unit/miner-ci-poller.test.ts already has thorough coverage for pollCheckRuns — 13 cases including pagination (#2621 regression), stale-conclusion normalization (#2621 regression), pending/neutral states, exact backoff-delay assertions, PR-head-drift re-fetch on force-push mid-backoff, input validation, and malformed/404 GitHub responses. So this isn't starting from zero, and duplicating any of the above would be wasted effort.

Three edge cases the current suite genuinely does not exercise, confirmed by reading ci-poller.js's actual control flow rather than assuming:

1. Rate-limit responses. githubError (ci-poller.js:76-82) wraps any non-OK response into a generic github_{status} error with no special-casing for 403/429 — and, more importantly, pollCheckRuns's attempt loop (ci-poller.js:200-225) has no try/catch around fetchHeadSha/fetchCheckRuns at all, so a thrown error on attempt 1 of e.g. 5 aborts the entire poll immediately rather than consuming a backoff attempt and retrying. There's no test pinning this behavior today.
2. Mid-pagination partial failure. fetchCheckRuns's while (true) loop (ci-poller.js:165-192) has no per-page retry — if page 1 succeeds and page 2's fetch throws, the same uncaught-propagation gap applies. Untested.
3. A fetchFn rejection (network/timeout), as opposed to an HTTP error response. Every existing test mocks fetchFn to resolve with a Response (even the error cases resolve with a 404/malformed body). None reject the promise outright, so a real network timeout / abort path is unexercised.

These are real gaps, not just missing test count — (1) and (2) currently mean a single transient failure kills a whole poll with no retry, which is worth locking in with a test either way (as current behavior, or as a bug to fix alongside the test — flag whichever the implementer decides).

Deliverables

• Test: a 403/429 response propagates as a github_403/github_429 error and does NOT consume/retry through the remaining maxAttempts — document whether that's the intended behavior or file a follow-up if it should retry instead
• Test: a fetchFn promise rejection (simulating a network timeout/abort) during fetchHeadSha and during fetchCheckRuns propagates a clear error rather than hanging or silently swallowing
• Test: page 1 of check-runs succeeds and page 2's fetch fails mid-pagination — assert the resulting error/behavior is deterministic
• If any of the above reveals behavior worth changing (e.g., retrying on 429 specifically), scope that as an explicit, separate feat/fix note in the PR description rather than silently changing behavior under a test-prefixed title
• Keep using the existing injected fetchFn/sleepFn style from test/unit/miner-ci-poller.test.ts — no real network calls

References

• packages/gittensory-miner/lib/ci-poller.js:76-82 (githubError — no rate-limit special-casing)
• packages/gittensory-miner/lib/ci-poller.js:165-192 (fetchCheckRuns — pagination loop with no per-page retry)
• packages/gittensory-miner/lib/ci-poller.js:194-228 (pollCheckRuns — attempt loop with no try/catch around the fetch calls)
• test/unit/miner-ci-poller.test.ts (existing coverage to extend, not duplicate — see especially the pagination and backoff-timing tests already present)

[linear-code]

JSO-3268