Add a high-level MCP operation interceptor seam

Problem

Frameworks built on the high-level McpServer cannot add operation middleware without replacing SDK-owned handlers or reaching into private registries. Protocol._wrapHandler is too low-level: it runs outside McpServer routing, tool input/output validation, result projection, resource cache hints, and prompt validation.

This prevents a framework from safely wrapping tools/list, tools/call, resource operations, and prompt operations while preserving SDK validation and input_required behavior.

Proposed seam

Add an optional high-level aroundMcpRequest callback to ServerOptions. It should:

• cover the seven primitive operations owned by McpServer;
• run after method-specific routing and input validation;
• run before tool output validation/projection, resource cache-hint attachment, input-required handling, and protocol result validation;
• keep ordinary interceptor errors inside the existing tools/call isError conversion;
• derive request/result types from RequestTypeMap and HandlerResultTypeMap.

The low-level Server should continue to leave directly registered handlers unchanged.

This work needs to stack on #2501 because the consuming framework already uses that coordinated preview for the 2026-07-28 protocol and MCP Apps support.

Start by tracing McpServer routing and the existing Protocol._wrapHandler path, then inspect ServerOptions, RequestTypeMap, and HandlerResultTypeMap. Compare the seven primitive operations and the validation and error-handling stages described in the issue, while reviewing the coordinated preview in #2501. Done means the high-level seam covers those operations without changing directly registered low-level handlers.