cli: stored-auth injection should honor refresh_token, not just access_token #1665

Background

Surfaced in the @claude review of #1655 (the #1575 stored-auth suite). The CLI stored-auth injection path (--use-stored-auth) currently performs a blind injection of the persisted access_token only, ignoring any stored refresh_token. When the access token is expired, the CLI cannot transparently refresh it and the request fails, even though a valid refresh token is on disk.

This was intentionally deferred in #1575: honoring refresh_token pulls in the SDK refresh-grant path, which is beyond the "reuse an existing token" scope of that issue. It is recorded there only as a code/README TODO, so this issue makes it tracked work.

Scope

• On stored-auth injection, when the access token is absent/expired and a refresh_token is present, run the refresh grant to obtain a fresh access token before connecting.
• Reuse the existing SDK/core OAuth refresh path rather than hand-rolling the token request (see the core auth/ provider flows).
• Persist the rotated tokens back through the same storage the web backend writes ({servers, idpSessions} shape via core getStateFilePath() / parseOAuthPersistBlob), so web and CLI stay consistent.
• Tests: expired-access-token + valid-refresh-token → refresh → connect; refresh failure surfaces a clear error and the documented non-zero exit code.

References

• Declined item in cli: Wave 3 — programmatic review path (rollup of #1573–#1575) #1655 review (branch v2/1575-cli-stored-auth), code/README TODO.
• Related (older, different scope): Token refresh flow is not implemented #665 (token refresh flow not implemented), Requests to oauth the token endpoint with refresh_token grant type set invalid content-type header #1160.
• Part of the Tracking: re-implement PR #1510 (spec-conformant Apps host + programmatic review path) as scoped issues #1579 re-implementation effort (CLI lane).