Connection Info: surface and decode the id_token when the authorization server returns one

[cliffhall]

Split from #1937 (ask 4), deliberately narrowed.

Problem

When an authorization server returns an id_token alongside the access token, the Inspector stores it and then never shows it. Someone debugging why their OIDC-fronted authorization server issued the claims it did has no way to see them without copying the token out of a network log by hand.

What already exists

Almost all of the pieces:

• The id_token is already persisted — it is part of the SDK's OAuthTokens, stored under byIssuer[issuer].tokens (core/auth/store.ts:28-33, :50-70) and snapshotted to ~/.mcp-inspector/storage/oauth.json (core/auth/node/storage-node.ts:29-38). Nothing strips it.
• A JWT decoder already ships — decodeJwtPayload (core/auth/ema/jwt.ts:49, header + payload, explicitly no signature verification), used today by the EMA leg.
• A "Decode JWT" toggle already ships, for the access token — clients/web/src/components/groups/ConnectionInfoContent/OAuthAccessTokenField.tsx:73-100.

What is missing is only the wiring: oauthDetailsFromConnectionState.ts:11-27 surfaces accessToken and (for EMA) idpSession, and never reads tokens.id_token.

Scope

Surface an ID Token field in Connection Info when the stored token set carries one, reusing the existing access-token field component and its decode toggle. Absent when there is no id_token — no empty row.

Explicitly out of scope

This is a viewer, not a flow. id_token has no role in MCP authorization: the spec is plain OAuth 2.1 with access tokens, and OIDC appears only as a metadata discovery format (/.well-known/openid-configuration). This issue must not grow into an OIDC login mode, signature verification, or treating the id_token as an identity credential. The enterprise (EMA) path already does real OIDC where it is warranted — core/auth/ema/idpOidc.ts, core/auth/storage.ts:217-222.

Points 5 and 6 of #1937 — persisting the refresh token and re-saving a refreshed id_token — need no work: both already happen, since the SDK's auth() writes the whole token set back through saveTokens.

Testing

Unit coverage for the mapper's present/absent branches and the field's decode toggle, clearing the >=90% per-file gate. Confirm the token stays masked by the existing redaction rules wherever it is logged (clients/web/src/utils/maskSecrets.ts:21-27).

[cliffhall]

Shipped in #2023, merged to v2/main as 298510c7. Closing manually because Closes #N does not auto-close for PRs targeting v2/main (a non-default branch).