docs(sso): the domain-verification doors answer one off code and a not-found on

The callout under "Domain verification (opt-in)" said that with
OS_SSO_DOMAIN_VERIFICATION unset the two steps report it differently and that
verify-domain passes the inner 404 through. Both doors answer
400 DOMAIN_VERIFICATION_DISABLED with the switch unset, without reaching the
inner endpoint; with it on, an unknown providerId gets 404 RESOURCE_NOT_FOUND
from either door. The "match on the code" advice keeps a true reason: step 2's
NO_PENDING_VERIFICATION is a 404 as well.

Claude-Session: https://claude.ai/code/session_01LYXc6ckoWuZyVZpWYizdMh
Co-authored-by: Claude <noreply@anthropic.com>

Author: claude

content/docs/permissions/sso.mdx

@@ -279,9 +279,10 @@ after DNS propagates.
 <Callout type="info">
 **The mounts are unconditional; the switch controls the endpoint behind them.**
 Both routes exist whether or not `OS_SSO_DOMAIN_VERIFICATION` is set — and with
-it unset the two halves report that differently, so match on the code rather than
-the status: step 1 answers **400 `DOMAIN_VERIFICATION_DISABLED`**, step 2 passes
-the inner **404** through with an explanatory message. Either way an anonymous
+it unset there is no endpoint behind them, so both steps answer **400
+`DOMAIN_VERIFICATION_DISABLED`**. With it on, either step answers an unknown
+`providerId` with **404 `RESOURCE_NOT_FOUND`**; step 2's `NO_PENDING_VERIFICATION`
+is a 404 too, so match on the code rather than the status. Either way an anonymous
 caller gets **401 `UNAUTHENTICATED`** and a signed-in non-platform-admin **403
 `PERMISSION_DENIED`** — identity is answered before capability, so a stranger
 cannot use these routes to probe which features an environment has enabled.