docs(core): name standard-header-validation rung at call site + test header; add precedence caveat

The serveModern call-site comment and the server stdHeaderValidation
test header still attributed the presence/Mcp-Name rejections to the
edge era-classification rung after 5779aab re-stamped them onto the
dedicated standard-header-validation rung. Both now name the rung
explicitly (and note the classifier's mismatch cells stay on
era-classification).

The new rung's documented order (8) is also not the observed
precedence — serveModern evaluates it immediately after the
supported-revision gate, before the dispatch rungs (5-6) and the
capability gate (7). Rather than renumber (wider blast across the
ladder table and the param-header rung), add a precedence caveat to
its rationale, mirroring the client-capabilities entry's caveat.

Author: felixweinberger

packages/core/src/shared/inboundClassification.ts

@@ -337,7 +337,10 @@ export const INBOUND_VALIDATION_LADDER: readonly InboundValidationRungDescriptor
             'SEP-2243 standard `Mcp-Method` / `Mcp-Name` headers — presence, sentinel decoding, and `Mcp-Name` ↔ body cross-check ' +
             '— are validated by the HTTP entry on a modern-classified request after the supported-revision gate and before ' +
             'dispatch. The classifier’s own header-mismatch cells (protocol-version, `Mcp-Method` mismatch) stay on the edge ' +
-            '`era-classification` rung; this rung carries the entry-layer presence/`Mcp-Name` half.'
+            '`era-classification` rung; this rung carries the entry-layer presence/`Mcp-Name` half. The documented order ' +
+            '(after method resolution, params validation, and the capability gate) is not the observed precedence: serveModern ' +
+            'evaluates this rung immediately after the supported-revision gate, so a request that fails several rungs is ' +
+            'answered by this gate before the dispatch rungs (5–6) and the capability gate (7) are consulted.'
     },
     {
         rung: 'param-header-validation',

packages/server/src/server/createMcpHandler.ts

@@ -647,9 +647,10 @@ export function createMcpHandler(factory: McpServerFactory, options: CreateMcpHa
         }
 
         // SEP-2243 standard-header presence and `Mcp-Name` cross-check
-        // (`era-classification` rung; the `MCP-Protocol-Version` and
+        // (`standard-header-validation` rung; the `MCP-Protocol-Version` and
         // `Mcp-Method` *mismatch* cells are already answered inside
-        // `classifyInboundRequest`). Evaluated after the supported-revision
+        // `classifyInboundRequest` on the edge `era-classification` rung).
+        // Evaluated after the supported-revision
         // gate so an envelope naming a revision this endpoint does not serve
         // is still answered with `-32004` (the supported list is the more
         // useful answer to a client speaking the wrong revision); evaluated

packages/server/test/server/stdHeaderValidation.test.ts

@@ -8,9 +8,10 @@
  * header, a missing `Mcp-Name` header on a `tools/call` / `prompts/get` /
  * `resources/read` request, an `Mcp-Name` value disagreeing with
  * `params.name` / `params.uri`, and an invalid `Mcp-Name` Base64 sentinel are
- * all rejected `400` / `-32001` (`HeaderMismatch`) — the same shape and rung
- * the classifier already emits for the `MCP-Protocol-Version` and
- * `Mcp-Method` mismatch cells. Legacy-era traffic is byte-unchanged.
+ * all rejected `400` / `-32001` (`HeaderMismatch`) on the
+ * `standard-header-validation` rung — the same shape the classifier already
+ * emits for the `MCP-Protocol-Version` and `Mcp-Method` mismatch cells on the
+ * edge `era-classification` rung. Legacy-era traffic is byte-unchanged.
  */
 import {
     CLIENT_CAPABILITIES_META_KEY,