feat(github): collapse status reads with GraphQL rollups

[JSONbored]

Parent: #1936

Problem

The largest remaining avoidable GitHub cost is repeated status/check/branch-protection style reads. Caching and backpressure help, but beta-stable should reduce the number of calls created in the first place.

Requirements

• Replace high-volume repeated REST reads with fewer equivalent reads where safe.
• Prefer GraphQL for aggregate PR/check/status snapshots when it can collapse many REST calls into one bounded query.
• Keep REST for writes, webhook-specific actions, and endpoints where GraphQL would add semantic risk.
• Preserve correctness for required checks, branch protection, mergeability, skipped checks, and gate decisions.

Deliverables

• Identify the top GitHub endpoints by live metrics/logs.
• Build a targeted GraphQL/status-rollup path for PR status/check summary reads.
• Cache repo/base-branch policy snapshots for a bounded TTL where correctness allows.
• Add regression tests proving gate decisions match the REST path for pending, success, failure, skipped, missing, and required-check cases.

Acceptance criteria

• The hot status/check path performs materially fewer GitHub requests per PR pass.
• GraphQL failures fail closed or fall back safely without creating request storms.
• Review/gate behavior remains semantically equivalent.
• Metrics show REST pressure decreases after deployment.

Expected outcome

The system stops burning GitHub budget on repeated status reads and uses GitHub APIs in a way that scales better for active repos.

[linear-code]

JSO-2026

[JSONbored]

Implementation notes — GraphQL status rollup

Exact REST call cluster this collapses (one gate/maintenance pass, one PR)

fetchLiveCiAggregate (src/github/backfill.ts:2123-2285) + siblings currently issue, per PR pass:

• GET /commits/{sha}/check-runs?per_page=100&page=N — paginated (:2160)
• GET /commits/{sha}/status?per_page=100&page=N — paginated combined status (:2197)
• GET /commits/{sha}/check-suites?per_page=100 — the late-materialization backstop (:2253)
• GET /branches/{base}/protection/required_status_checks — required contexts (:2100; already branch_protection-cached, 20 min)
• GET /pulls/{n} — fetched up to 3× for mergeable_state (:2296), state (:2305), headSha (:2314)

That's ~5–8 REST calls (plus pagination) against the core bucket, per PR, per sweep.

Why GraphQL is the high-leverage move (not just fewer calls)

GraphQL uses a separate points-based bucket from the REST core bucket (githubGraphQl, src/github/backfill.ts:2894). One bounded query costs ~1 point regardless of payload size, so this doesn't just reduce calls — it moves the hot path off the exhausted REST bucket entirely. A single query returns:

pullRequest(number: N) {
  state mergeable mergeStateStatus
  commits(last: 1) { nodes { commit {
    statusCheckRollup { contexts(first: 100) { nodes {
      __typename
      ... on CheckRun    { name conclusion status isRequired(pullRequestId: $id) detailsUrl checkSuite { app { slug } } }
      ... on StatusContext { context state isRequired(pullRequestId: $id) targetUrl description }
    } pageInfo { hasNextPage } } }
    checkSuites(first: 50) { nodes { app { slug } status } }
    oid
  } } }
}

statusCheckRollup.contexts unifies check-runs and classic statuses (so codecov/patch etc. are included), and isRequired(pullRequestId:) returns required-ness inline — eliminating the separate required_status_checks REST read. mergeable + mergeStateStatus + state + oid replace all three GET /pulls/{n} reads.

Correctness — must preserve fetchLiveCiAggregate semantics exactly

The gate merge/close decision reads this, and src/github/backfill.ts is a guarded path (src/review/guardrail-config.ts:43), so the GraphQL mapper must reproduce every rule the REST path enforces:

• Skip our own App's check-runs (isOwnGitHubAppCheckRun); first-party (github-actions) detection for the fold-all backstop.
• Failing conclusions → failingDetails; only a required pending/absent context holds the gate.
• Required-context absence → pending (never silently "passed").
• Fold-all mode + missingConventionalValidateAggregate → pending; check-suites still-queued/in_progress → pending.
• Fail-closed on any incomplete read (pagination overflow, GraphQL error) — never certify "passed" on partial data.

Recommended shape (safe for one-shot gate + guarded path)

• New src/github/graphql-status-rollup.ts: the query + a mapper to the existing LiveCiAggregate (+ PR-snapshot) shape, reusing githubGraphQl.
• Flag-gated, OFF by default (GITHUB_STATUS_ROLLUP_GRAPHQL truthy env, *-wire.ts pattern) → byte-identical deploy; REST path is the fallback on any GraphQL error/partial (fail-closed).
• Attribute the GraphQL call with a real admission key (feeds fix(github): complete budget attribution for rate-limit admission #1940) instead of null.
• Regression matrix asserting GraphQL-mapped verdict === REST verdict for: pending, success, failure, skipped, missing/absent-required, non-required-red, fold-all, and incomplete-read fail-closed.

Also folding in the N2 win: collapse the 3× GET /pulls/{n} into one memoized full fetch even on the REST fallback path.