MCP server wrapper misses messages delivered during transport start

## Problem

`wrapMcpServerWithSentry` instruments an MCP transport only after the wrapped
server's `connect()` promise resolves. Both supported MCP TypeScript SDK
generations install their transport callbacks and then call
`transport.start()` before that promise resolves.

A transport is allowed to deliver already-buffered messages from `start()`.
The official `InMemoryTransport` does this in both SDK v1.30.0 and v2.0.0. If
an `initialize` request is queued before the server connects, that first
request reaches the server before Sentry wraps `onmessage`, so no MCP span is
created for it.

## Reproduction

1. Create an official linked `InMemoryTransport` pair.
2. Start `Client.connect()` first so its `initialize` request is queued on the
server transport.
3. Connect a server wrapped with `wrapMcpServerWithSentry`.
4. Inspect the emitted MCP spans.

## Actual behavior

The queued `initialize` request is handled during `transport.start()` and is
missing from Sentry. Later requests are instrumented after `connect()`
completes.

## Expected behavior

- Instrument the callbacks after the MCP SDK installs them but before
`transport.start()` can deliver its first message.
- Preserve the transport's `start()` receiver, promise, errors and property
shape.
- Restore the temporary interception after the connection attempt.
- Preserve the existing post-connect behavior for transports whose `start`
method cannot be intercepted or is not invoked.
- Capture the first request exactly once in MCP SDK v1 and v2, both in v11's
default Sentry-only mode and its optional Sentry-managed
OpenTelemetry-compatible mode (`enableOpenTelemetrySetup: true`).

Start by tracing wrapMcpServerWithSentry through the wrapped server's connect() flow and the transport.start() call, comparing MCP SDK v1 and v2 callback setup. Reproduce the queued initialize request with linked InMemoryTransport pairs, then verify that the first request is captured exactly once in both Sentry-only and enableOpenTelemetrySetup modes while receiver, errors, promise, property shape, and post-connect behavior remain intact.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.