MCP server wrapper resolves genAI capture policy before a Sentry client is available #23436

Problem

wrapMcpServerWithSentry resolves unspecified recordInputs and
recordOutputs settings when the server is wrapped. If no Sentry client is
bound yet, both settings fall back to true and remain fixed for the lifetime
of that wrapper.

Wrapping before client setup is a normal ordering in Node applications that
import their MCP server before Sentry.init, and in Cloudflare Durable Objects
whose MCP server is initialized as an instance field. A later client configured
with dataCollection.genAI.inputs: false or
dataCollection.genAI.outputs: false is therefore ignored, and MCP input or
output content can still be recorded.

This behavior lives in the shared transport instrumentation and affects both
sessionful MCP SDK v1 and stable MCP SDK v2 paths.

Reproduction

1. Construct and wrap an MCP server before a Sentry client is bound.
2. Initialize the relevant Sentry client with GenAI input and output collection disabled.
3. Call a tool with unique marker content.
4. Inspect the resulting MCP span.

Actual behavior

The span can contain attributes such as mcp.request.argument.<name> and
mcp.tool.result.content even though the active client's data collection
policy disables them.

The wrapper also cannot honor different client policies for concurrent
operations because one policy was cached for every operation.

Expected behavior

• Explicit recordInputs and recordOutputs wrapper options take precedence independently.
• Unspecified fields inherit from the client active when the operation begins.
• A request's policy remains attached to its response, even if the response completes under a different scope.
• Incoming and outgoing notifications resolve policy when their operation begins.
• Structural MCP metadata remains available when content collection is disabled.
• The existing true fallback remains unchanged when neither a client policy nor an explicit override exists.