Cover CIMD-only client authorization with no DCR endpoint

Is your feature request related to a problem? Please describe.

auth/basic-cimd advertises client_id_metadata_document_supported: true and checks that the client presents the scenario's fixed CIMD URL as its client_id, but it still advertises and serves Dynamic Client Registration. auth/pre-registration removes the advertised endpoint only while supplying static credentials.

The suite therefore does not cover this combination:

• CIMD supported
• No registration_endpoint
• No pre-registered credentials
• Successful authorization, token exchange, and protected MCP request using the CIMD URL as client_id

Issue #34 was closed before this combination was covered.

At SHA 81eb1c3, createAuthServer.ts:726 mounts POST /register unconditionally. Consequently, disableDynamicRegistration removes registration_endpoint from metadata but does not make registration unavailable.

Runtime proof at SHA 81eb1c3: with disableDynamicRegistration: true, a POST /register returns 201 and records the client-registration check. I can provide the full reproduction on request.

Describe the solution you'd like

Tighten the existing stateful auth/basic-cimd scenario for specification version 2025-11-25 so that:

• The authorization server advertises CIMD without a registration endpoint.
• POST /register is unavailable.
• Any attempted dynamic registration is reported as a conformance failure.
• The client presents the scenario's fixed CIMD URL as its client_id.
• The token exchange completes using that client_id.
• An authenticated MCP call completes with a valid bearer token.

The shared helper correction would also change the pre-registration and WIF scenarios: a misbehaving client that POSTs /register would receive 404 instead of being silently registered. Their intended clients use supplied credentials and remain green.

Describe alternatives you've considered

The alternative is to target the 2026-07-28 stateless path. The bundled runAuthClient() also needs a separate 2026 stateless-lifecycle fix; that broader reference-client change is outside this issue.

Additional context

This gap was found during live interoperability testing of an mcp-sso authorization server over public HTTPS, using real identity-provider grants and protected MCP tool calls. Against the same CIMD-only server configuration, Claude Code 2.1.220 and the ChatGPT connector completed authorization using a URL-shaped client ID, while Codex 0.146.0 and 0.147.0-alpha.1 stopped after authorization-server discovery with Dynamic client registration not supported. The Codex reproduction and request logs are recorded in openai/codex#13200.

That product difference prompted the conformance-suite audit: the existing suite was green because auth/basic-cimd still made DCR available, so it did not exercise the configuration that distinguished these clients.

I propose targeting the existing 2025-11-25 scenario. CIMD-only was already valid there: clients and authorization servers SHOULD support CIMD, DCR is a MAY retained for backwards compatibility, and the client priority order ranks CIMD above DCR.

This covers a valid, previously untested combination without asserting the 2026 DCR deprecation retroactively, and keeps the change to one reviewable unit. Happy to sequence it differently if the maintainers prefer.

Start with src/scenarios/client/auth/helpers/createAuthServer.ts around line 726 and the existing stateful auth/basic-cimd scenario for 2025-11-25. Trace how disableDynamicRegistration affects metadata and POST /register, then run the scenario to verify that registration is unavailable while CIMD authorization, token exchange, and the authenticated MCP request complete successfully.