feat: surface and decode the OAuth id_token in Connection Info (#2019)

When an authorization server returns an `id_token` alongside the access
token, the Inspector already persisted it and never showed it. Wire it
through to Connection Info as a viewer.

- Generalize `OAuthAccessTokenField` into `OAuthTokenField` (label + token),
  so the ID Token row reuses the existing copy control and "Decode JWT"
  toggle rather than duplicating them. Access-token behavior is unchanged.
- `oauthDetailsFromConnectionState` now surfaces `tokens.id_token` as
  `idToken`, omitted entirely when absent so no empty row renders.
- Docs: update the two `specification/` references to the renamed field.

This is deliberately a viewer, not a flow: no OIDC login mode, no signature
verification, and the `id_token` is never treated as a credential. The EMA
path is untouched. `id_token` is already in `maskSecrets`'
`JSON_SENSITIVE_KEYS`, so it stays masked in the Network tab — no gap.

Signed-off-by: cliffhall <cliff@futurescale.com>

specification/v2_ux.md

@@ -294,7 +294,7 @@ Shown as a modal or dedicated screen after successful connection.
 - Server capabilities: Tools, Resources, Prompts, Logging, Completions, Tasks, Experimental
 - Client capabilities: Sampling, Elicitation, Roots, Tasks, Experimental
 - Display server instructions if provided
-- Show OAuth connection snapshot when applicable (`InspectorClient.getOAuthState()` → `OAuthConnectionState`): protocol, authorization status, client id, EMA IdP session, cached auth URL, scopes, access token with copy and in-place JWT decode (`OAuthAccessTokenField`)
+- Show OAuth connection snapshot when applicable (`InspectorClient.getOAuthState()` → `OAuthConnectionState`): protocol, authorization status, client id, EMA IdP session, cached auth URL, scopes, and the stored tokens — access token, plus the `id_token` when the authorization server returned one — each with copy and in-place JWT decode (`OAuthTokenField`)
 
 ### Feature Screens