GitHub contributors API called without authentication, exposing build to rate-limit failures

[ooloth]

Current state

gatsby-config.js fetches contributor data from the GitHub API at build time without authentication. Unauthenticated requests share a rate limit of 60 per hour per IP address. When the limit is exhausted, GitHub returns a 403 or 429 with an error body that describes the rate-limit policy and the endpoint that was blocked. This error propagates into the build output and any log sink that captures it, exposing internal build details and the fact that the site uses unauthenticated API access.

Ideal state

• The GitHub API call is authenticated with a scoped public_repo-read token stored as a CI secret environment variable
• Rate-limit or auth errors are caught and handled gracefully — the build falls back to an empty contributor list or a cached result rather than failing and logging GitHub's error body

Out of scope

• Changing which contributor data is displayed
• Adding a persistent contributor cache beyond what the build currently does

Starting points

• gatsby-config.js — the GitHub API call for contributor data

QA plan

1. Exhaust the IP's unauthenticated rate limit (or mock a 403 response) and trigger a build — expect the GitHub error body appears in build output today
2. After fix, confirm the build uses an authenticated token and falls back gracefully on a 403/429 without logging GitHub's error body

Done when

The GitHub contributors API is called with an authenticated token, and rate-limit errors are handled without propagating GitHub's error body into build or log output.