#22656: fix(providers): increase slow_down back-off to 5 s per RFC 8628

## Summary The GitHub Device Flow OAuth polling loop adds only 2 seconds when the server returns `slow_down`, violating RFC 8628 §3.5 which requires a 5-second increase. ## Bug ```ts // src/providers/github-copilot-auth.ts, line 102 if (err === "slow_down") { await new Promise((r) => setTimeout(r, params.intervalMs + 2000)); // ^^^^ // RFC 8628 requires +5000 } ``` [RFC 8628 §3.5](https://datatracker.ietf.org/doc/html/rfc8628#section-3.5): > If the client receives the `slow_down` error, it MUST increase the polling > interval by 5 seconds for all subsequent requests to the token endpoint. Using only +2 s risks continued rate-limiting from the authorization server, which may cause the login flow to time out or fail. ## Fix ```ts await new Promise((r) => setTimeout(r, params.intervalMs + 5000)); ``` ## Test plan - [x] `npx oxfmt --check src/providers/github-copilot-auth.ts` — pass - [x] `npx oxlint src/providers/github-copilot-auth.ts` — 0 warnings, 0 errors - [x] `npx vitest run src/providers/github-copilot-token.test.ts --config vitest.unit.config.ts` — 3 tests pass 🤖 Generated with [Claude Code](https://claude.com/claude-code) <!-- greptile_comment --> <h3>Greptile Summary</h3> This PR corrects the OAuth 2.0 Device Flow `slow_down` error handling in the GitHub Copilot authentication flow. The change increases the back-off interval from 2 seconds to 5 seconds to comply with RFC 8628 §3.5, which explicitly requires a minimum 5-second increase when receiving a `slow_down` error from the authorization server. **Key changes:** - Updated `src/providers/github-copilot-auth.ts:102` to add 5000ms instead of 2000ms when handling `slow_down` errors - This prevents continued rate-limiting during the device code polling loop and improves reliability of the login flow The fix is minimal, well-documented in the PR description with RFC citation, and includes test verification. The change aligns the implementation with the OAuth specification and should reduce authentication failures caused by aggressive polling. <h3>Confidence Score: 5/5</h3> - This PR is safe to merge with minimal risk - The change is a simple, spec-compliant numeric constant correction (2000 → 5000) in error-handling logic. The modification directly addresses a standards violation with clear RFC reference, includes passing tests, and has no side effects on other functionality. The logic remains identical except for the corrected delay value. - No files require special attention _{Last reviewed commit: bff1fb6} <!-- greptile_other_comments_section --> <!-- /greptile_comment -->