fix(client/auth): use stored refresh_token on 401 instead of full re-authorization

[beraterkanelcelik]

Problem

When an OAuthClientProvider is reconstructed and loads previously stored tokens
via TokenStorage, a stored refresh_token is never used — every access-token
expiry forces a full interactive re-authorization.

Root cause, in async_auth_flow (src/mcp/client/auth/oauth2.py):

• _initialize() loads current_tokens from storage but does not restore
  token_expiry_time (it stays None). OAuthToken.expires_in is relative, so a
  reloaded provider has no way to know the token's absolute expiry.
• With token_expiry_time is None, is_token_valid() returns True for the
  loaded token regardless of its real state, so the proactive-refresh branch
  if not is_token_valid() and can_refresh_token() is skipped.
• The server then rejects the stale access token with 401, but the 401 branch
  proceeds directly to a full authorization-code grant. It never attempts a
  refresh_token grant — even when a valid refresh_token and client_info are
  present in storage.

This is especially visible for clients that build a fresh provider per request and
rely on persisted tokens: they re-authorize interactively on every access-token
expiry instead of refreshing silently.

Fix

In the 401 branch of async_auth_flow, after metadata discovery and before
client registration / authorization, attempt a refresh_token grant when
can_refresh_token() is true. The discovery already performed in that branch
resolves the token endpoint, so the stored refresh_token can be used directly.
If the refresh fails, the flow falls back to the existing full re-authorization
path.

Tests

Adds to tests/client/test_auth.py:

• test_initialize_does_not_restore_token_expiry — documents the precondition
  (is_token_valid() is True after _initialize() loads a stored token,
  because expiry isn't restored).
• test_reloaded_provider_uses_refresh_token_on_401 — drives the full
  reload → 401 → refresh path and asserts a refresh_token grant is issued (not a
  new authorization) and the original request is retried with the refreshed token.
• test_reloaded_provider_falls_back_to_reauth_when_refresh_fails — asserts the
  flow falls back to full re-authorization when the refresh grant fails.

All existing auth tests continue to pass.