- fixes#7850
- fetch the account model catalog before policy updates
- update only known, tool-capable, unconfigured models
- retry throttled login requests within a bounded delay
- preserve the existing non-retrying refresh behavior
The login-time policy updates can drain the Copilot API rate-limit
bucket, in which case the follow-up GET /models is rejected with 429
(observed response: retry-after: 2, body 'too many requests') and login
aborts. Honor Retry-After and retry once instead of failing (#8121).
Batching policy POSTs at concurrency 4 still bursts 30 requests during
login, which trips the Copilot API rate limiter and makes the following
GET /models fail with 429, aborting login (#8121). Send the policy
updates one at a time instead.
Move provider auth and OAuth flows onto pi-ai Models, compose models.json and extension overlays through ModelRuntime, and retain ModelRegistry as an extension compatibility facade.
GitHub's device flow documents slow_down as a rate limit: a poll that
arrives inside the throttle window is answered with slow_down instead of
the token, and the response's interval field reports the new required
minimum ("adds 5 seconds to the last interval"). A client that only
tracks its own +5s increment can stay behind the server's ratcheting
requirement when its timers fire early - common with WSL/VM clock drift
(microsoft/WSL#10006) - so every subsequent poll keeps hitting the rate
limit and login appears to hang forever even after the browser reports
the device as authorized.
Adopt the server-provided interval when a slow_down poll result carries
one, falling back to the RFC 8628 section 3.5 +5s increment otherwise.
GitHub Copilot passes the interval field through.
This restores part of the #1994 mitigations that were lost in the #4788
device-code refactor.
refs #6187
