Recognize GitHub 429 responses as rate limits

[jskoiz]

Verified against main at 715c52e.

Impact

GitHub documents that primary or secondary REST rate limiting can return either HTTP 403 or 429. The GitHub client currently assigns github_rate_limit only to qualifying 403 responses, and the hosted fallback also recognizes only 403. An upstream 429 therefore becomes a generic request failure.

For public dashboards this loses normalized recovery copy, Retry-After / reset timing, stale browser-cache fallback, and the optional sign-in action. The UI instead categorizes the response as the app's generic “Too many requests” state, even though its own rate limiter and GitHub's upstream quota require different recovery behavior.

Reference: GitHub REST API rate-limit behavior.

Concrete code references

• The upstream classifier requires status 403 before checking rate-limit headers or message.
• Retry timing is already parsed from Retry-After and X-RateLimit-Reset.
• The hosted compatibility check also accepts only status 403.
• The browser treats an untagged 429 as a generic app rate limit.

Acceptance criteria

• A GitHub API 429 is classified as github_rate_limit and retains endpoint, status, retryAfterSeconds, and retryAt metadata when available.
• Public hosted responses use the existing normalized GitHub-quota payload for both qualifying 403 and 429 upstream responses.
• The browser uses stale matching public cache and sign-in recovery for an upstream GitHub 429 exactly as it does for a GitHub 403 rate limit.
• The application's own app_rate_limit 429 responses remain distinguishable and keep their current generic local-throttle treatment.

Test expectations

• Extend server/github-client.test.ts with 429 cases using Retry-After and X-RateLimit-Reset.
• Extend server/hosted-server.test.ts to prove a GitHub 429 becomes the normalized public quota payload.
• Extend src/App.test.tsx to prove stale-cache and sign-in recovery for that payload.
• Run both Vitest projects and npm run check.

Dependencies / order

Independent and safe to land early.

Non-goals

• Automatically retrying rate-limited GitHub calls.
• Treating every application-generated 429 as a GitHub quota response.
• Changing per-client or per-user application throttle limits.
• Logging or returning raw upstream error bodies.