Avoid retaining unusable OpenID refresh tokens when reuse is disabled #47

Follow-up from #46 and LibreChat-AI/LibreChat#13007.

Problem

The admin panel stores the refreshToken returned by /api/admin/oauth/exchange in its server-side session. The LibreChat backend now correctly rejects /api/admin/oauth/refresh with 403 TOKEN_REUSE_DISABLED when OPENID_REUSE_TOKENS=false, but the admin panel may still retain an IdP refresh token that cannot be used.

This does not currently extend the session when reuse is disabled because the backend refresh endpoint fails closed. The concern is defense-in-depth and policy consistency: if token reuse is disabled, the admin-panel BFF should avoid keeping an unnecessary sensitive refresh token in session state, or clear it once the backend reports that reuse is disabled.

Proposed direction

Coordinate with the LibreChat backend so /api/admin/oauth/exchange omits refreshToken when OPENID_REUSE_TOKENS=false, then make sure the admin panel handles that absence as a non-refreshable OpenID session.

As an admin-panel-side hardening step, consider detecting TOKEN_REUSE_DISABLED from /api/admin/oauth/refresh and clearing the stored refreshToken so the BFF does not keep retrying or retaining an unusable token.

Acceptance criteria

• When the backend does not return refreshToken from admin OAuth exchange, the admin panel stores no refresh token and falls back to normal re-login at bearer expiry.
• If /api/admin/oauth/refresh returns TOKEN_REUSE_DISABLED, the admin panel clears the stored refresh token and does not keep retrying refresh for that session.
• Existing OPENID_REUSE_TOKENS=true behavior remains unchanged.
• Add focused tests for missing exchange refresh token and/or TOKEN_REUSE_DISABLED handling.

This is not a blocker for #46 because the backend already refuses to use the token when reuse is disabled.