Server Settings: disambiguate EMA OAuth credential fields (#1692) (#1749)

* Server Settings: disambiguate EMA OAuth credential fields (#1692)

Under enterprise-managed authorization the OAuth Settings "Client ID" /
"Client Secret" fields hold the *resource authorization server* credentials
(EMA leg 3 — the Test Client from the xaa.dev resource registration), not the
app/IdP pair configured in Client Settings. The unqualified labels sat under a
toggle naming the enterprise IdP, pulling readers toward the wrong pair.

- When enterpriseManaged is on, relabel to "Resource AS Client ID" /
  "Resource AS Client Secret" and add a description naming the resource
  authorization server and pointing the app pair back to Client Settings.
- Document the Scopes delimiter: space-separated (RFC 6749), with a warning
  that commas produce one invalid token, plus a placeholder example.

Adds tests for both label states and the scopes hint, plus an
EnterpriseManagedOAuth story.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01XNdjEPKLG637X8YmhDiEk5

* pr-screenshots: OAuth EMA field disambiguation proof shots (#1692)

Add before/after screenshots of the Server Settings → OAuth Settings fields
(EMA off = plain Client ID/Secret; EMA on = Resource AS Client ID/Secret) plus
the new space-separated Scopes hint, with a README section documenting them.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01XNdjEPKLG637X8YmhDiEk5

* Address review: genericize EMA copy, reuse enterpriseManaged const (#1692)

- Drop the hardcoded xaa.dev staging host from the resource-AS field
  description (it's a general EMA concept, not env-specific); phrase it as
  "the resource authorization server's registered client credential (EMA leg
  3)". Also trims the copy's overlap with the checkbox description.
- Reuse the existing `enterpriseManaged` const for the EMA Checkbox's `checked`
  prop instead of recomputing `settings.enterpriseManaged ?? false`.
- Update the test assertion and pr-screenshots README/EMA-on screenshot to
  match the new copy.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01XNdjEPKLG637X8YmhDiEk5

* Client Settings: mirror EMA disambiguation (IdP-qualified labels) (#1692)

The Server Settings OAuth fields now label the leg-3 resource-AS pair
explicitly; make Client Settings parallel so each modal names its pair and
points at where the other lives.

- Relabel the EMA credential fields to "IdP Client ID" / "IdP Client Secret"
  (parallel to Server Settings' "Resource AS Client ID/Secret"), so the label
  alone disambiguates without relying on the description.
- Add the reciprocal cross-reference to each description: these are the
  enterprise IdP pair (EMA legs 1–2), not the per-server resource authorization
  server credentials, which go in Server Settings → OAuth Settings.
- Update ClientSettingsForm/ClientSettingsModal tests for the new labels; add a
  pr-screenshots section + Client Settings screenshot.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01XNdjEPKLG637X8YmhDiEk5

---------

Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

pr-screenshots/README.md

@@ -1,3 +1,39 @@
+# Server Settings OAuth field disambiguation under EMA (#1692) — proof screenshots
+
+The **Server Settings → OAuth Settings** fields, rendered from the
+`ServerSettingsForm` Storybook stories. Under enterprise-managed authorization
+(EMA) these fields hold the *resource authorization server* credentials (leg 3 —
+its registered client), **not** the app/IdP pair configured in Client Settings.
+The unqualified labels sat directly under a toggle naming the enterprise IdP,
+making it easy to paste the wrong pair. See #1692.
+
+![OAuth Settings with EMA off — plain Client ID / Client Secret](ema-oauth-fields-plain.png)
+
+Enterprise-managed authorization **off** (the common case): the fields keep the
+plain **Client ID** / **Client Secret** labels. The **Scopes** field now
+documents its delimiter — _"Space-separated OAuth scopes (RFC 6749). Do not use
+commas — a comma-separated entry is sent as one invalid token and rejected by
+the authorization server."_ — with a `mcp tools:read env:read` placeholder.
+
+![OAuth Settings with EMA on — Resource AS Client ID / Secret](ema-oauth-fields-resource-as.png)
+
+Enterprise-managed authorization **on**: the same two fields relabel to
+**Resource AS Client ID** / **Resource AS Client Secret**, each gaining a
+description that names the resource authorization server (its registered client,
+EMA leg 3) and points the app client id/secret back to Client Settings.
+
+![Client Settings modal — IdP Client ID / IdP Client Secret](ema-client-settings-idp-fields.png)
+
+The reciprocal side in the **Client Settings** modal (Enterprise-Managed
+Authorization section). Its credential fields are relabeled **IdP Client ID** /
+**IdP Client Secret** — parallel to Server Settings' `Resource AS …` — and each
+description now points the *other* way: these are the enterprise IdP pair (EMA
+legs 1–2), **not** the per-server resource authorization server credentials,
+which go in Server Settings → OAuth Settings. Together the two modals close the
+loop: each names its pair and where the other lives.
+
+---
+
 # Connection Info extensions + `io.modelcontextprotocol/ui` (#1740) — proof screenshots
 
 End-to-end verification of the Phase 3 Connection Info UI against the legacy