Reduce GitHub API consumption to avoid rate-limit outages

Background

On 2026-06-17, shortly after deploying #463, Pulldasher went down with:

GET /orgs/iFixit/members/danielbeardsley - 403
Request quota exhausted for request GET /orgs/{org}/members/{username}

Root cause

The org-membership 403 is a symptom, not the cause. That call lives only in lib/authentication.js on the login callback — it failed because the whole hourly REST quota was already drained, so login couldn't complete (app appears "down").

What drained the quota was the deploy restart. On boot, app.js runs refresh.openPulls(), sending every open pull (across all repos) through git-manager.parse(). Each parse() is ~8–15 REST requests:

N open pulls × ~10 calls, back-to-back, blew the 5000/hr quota. Any restart can trigger this; #463 was simply the deploy that tipped it over. #463's own code (models/signature.js parseReview) adds zero API calls.

Proposed paths (ranked)

1. ETag conditional requests — a conditional request returning 304 Not Modified (If-None-Match + Authorization) does not count against the primary rate limit (docs). Octokit does not cache by default. On restart almost every open pull is unchanged, so a per-URL ETag cache turns the startup resync from thousands of billed calls into ~0. Smallest change, biggest win. Draft PR incoming.
2. Trim getAllJobRuns — heaviest per-pull cost (workflow runs + one jobs call per run) and overlaps getCombinedStatusForRef. Switch to the Checks API or drop the job-level fetch and lean on the check_run webhook.
3. Don't full-resync on boot — pulls are already warmed from the DB (app.js:61-69); gate or pace the refresh.openPulls() cold-start spike.
4. Targeted webhook handling — issue_comment edited/deleted and pull_request_review edited/dismissed do a full ~10-call parse. Handle incrementally (e.g. a dismissed approval just invalidates its CR signature by comment_id).
5. GraphQL batch — one query replaces ~8 REST calls per pull. Bigger lift; only if 1–4 fall short.

Minor: cache the login org-membership check (short TTL) so an exhausted quota doesn't lock everyone out of the dashboard.

Ask

Aligning on the path forward. Starting with #1 as a draft to evaluate.

Start by reading app.js:61-69 and tracing refresh.openPulls() into git-manager.parse(), then inspect the REST calls listed in the issue and lib/authentication.js. Compare the proposed ETag approach with the incoming draft PR and measure whether restart and webhook refreshes avoid exhausting the GitHub API quota without breaking pull refresh or login.