MCP OAuth keeps fuller sign-in discovery details and no longer throws them away

What

When you sign in to an MCP server (an external tool server Claude Code connects to) with OAuth, Claude Code stores details of how it found the server's sign-in service, in discoveryState. Before, only authorizationServerUrl was kept. Now it keeps more and loses less.

• discoveryState now also keeps oauthMetadataFound and authServerMetadataUrl alongside authorizationServerUrl, including when credentials are copied or saved.
• saveTokens now writes a merged discoveryState with the authorization server used at sign-in (discovered or overridden), the metadata URL that was served, and whether the sign-in was interactive. Plain token saves used to leave it alone.
• After an interactive sign-in, a helper builds the stored state, sets oauthMetadataFound: true and clears authServerMetadataUrl to null. A non-interactive refresh keeps the previous value.
• A new internal flag, _flowDiscoveryStateFromConfiguredUrl, tracks whether the sign-in's discovery state came from a configured metadata URL; when it did, the overridden authorization server URL is taken from that state.
• invalidateCredentials('discovery') now keeps a trimmed copy (authorization server, oauthMetadataFound, authServerMetadataUrl) instead of clearing it.
• saveDiscoveryState merges with the previous state, records which configured authServerMetadataUrl served the metadata, and keeps an earlier registrationNotOfferedAt when no metadata came back.
• The XAA silent refresh records which server issued the token by merging, instead of overwriting discoveryState.

Why

Later token refreshes and re-sign-ins can go back to the same authorization server that issued the token, rather than losing that pointer. This matters most for MCP servers with a configured or non-standard metadata URL.