createMcpHandler: Mcp-Param header validation and scope challenges only run when the factory returns an McpServer #3126

In 2.4.0, createMcpHandler runs two pre-dispatch checks for modern requests, but only when the factory's product is an McpServer:

if (route.messageKind === "request" && route.message.method === "tools/call" && product instanceof McpServer) {
  const inputSchema = product.toolInputSchemaJson(toolName);
  // scanXMcpHeaderDeclarations → validateMcpParamHeaders → rejectionResponse
}
if (route.messageKind === "request" && product instanceof McpServer) {
  const challenge = await findScopeChallenge([route.message], authInfo, (context) => product.resolveScopeChallenge(context));
  // createScopeChallengeResponse
}

The factory may return a low-level Server instead. In that case both checks are skipped without any warning:

• SEP-2243 Mcp-Param-* header validation. A request whose headers disagree with its tool arguments goes straight through to the handler.
• OAuth scope challenges. No 403 insufficient_scope is ever produced.

A low-level Server is the only option when the tool list can't be fixed when the instance is created. Examples:

• visibility that depends on the request's client capabilities;
• pagination cursors bound to the caller;
• extension methods;
• task and input-required results.

Such servers have to re-implement both checks before calling handler.fetch. scanXMcpHeaderDeclarations, validateMcpParamHeaders and createScopeChallengeResponse are not exported, so they have to be re-implemented from scratch rather than called.

Proposal, either of:

1. Handler options that work with any product (preferred):

   createMcpHandler(factory, {
     toolInputSchema?: (name: string, context) => JsonSchema | undefined,
     scopeChallenge?: ScopeChallengeHandler,
   })

   McpServer keeps supplying its own through toolInputSchemaJson and resolveScopeChallenge when the options are absent.
2. At minimum, export the helpers: scanXMcpHeaderDeclarations, validateMcpParamHeaders, findScopeChallenge and createScopeChallengeResponse. Servers built on Server could then reuse the exact SDK behavior.

Either way, it would help if the handler warned when a non-McpServer product skips these checks.

Context: we maintain an MCP server component on the low-level Server. It currently carries its own copy of the header validation and the scope-challenge responses for exactly this reason.