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