Send application_type during Dynamic Client Registration (SEP-837) (#2930)

.github/actions/conformance/expected-failures.2026-07-28.yml

@@ -28,32 +28,6 @@ client:
   # branch takes the per-request _meta path.
   - tools_call
 
-  # --- SEP-837 (application_type during DCR) ---
-  # The sep-837-application-type-present check only fires on 2026-version
-  # runs; the client omits application_type during Dynamic Client
-  # Registration, so every auth scenario that reaches DCR fails it on this
-  # leg (the same scenarios pass at their default version in the 2025 legs).
-  - auth/metadata-default
-  - auth/metadata-var1
-  - auth/metadata-var2
-  - auth/metadata-var3
-  - auth/scope-from-www-authenticate
-  - auth/scope-from-scopes-supported
-  - auth/scope-omitted-when-undefined
-  - auth/token-endpoint-auth-basic
-  - auth/token-endpoint-auth-post
-  - auth/token-endpoint-auth-none
-  - auth/offline-access-not-supported
-  # SEP-2468 (authorization response iss parameter) is implemented, but these
-  # 2026-introduced scenarios reach DCR and so still fail the application_type
-  # check above; they unblock with SEP-837, not SEP-2468.
-  - auth/iss-supported
-  - auth/iss-not-advertised
-  - auth/iss-supported-missing
-  - auth/iss-wrong-issuer
-  - auth/iss-unexpected
-  - auth/iss-normalized
-
   # --- Auth scenarios cut short by the 2026 connection lifecycle ---
   # The auth fixture flow drives the 2025 stateful lifecycle; the 2026-mode
   # mock rejects the MCP POST before the scope-escalation behaviour these

.github/actions/conformance/expected-failures.yml

@@ -26,18 +26,6 @@ client:
   # SEP-2352 (authorization server migration): client does not re-register when
   # PRM authorization_servers changes.
   - auth/authorization-server-migration
-  # SEP-837 (application_type during DCR): the check fires on every non-legacy
-  # spec version (the default LATEST is 2026-07-28). The client omits
-  # application_type during Dynamic Client Registration, so every scenario that
-  # reaches DCR fails it. SEP-2468 iss validation is implemented, so these now
-  # fail only on the application_type check, not on iss.
-  - auth/offline-access-not-supported
-  - auth/iss-supported
-  - auth/iss-not-advertised
-  - auth/iss-supported-missing
-  - auth/iss-wrong-issuer
-  - auth/iss-unexpected
-  - auth/iss-normalized
 
   # --- Pre-existing scenarios that fail on checks added after conformance 0.1.15 ---
   # SEP-990 (enterprise-managed authorization extension): no fixture handler /