Follow-up to #3875 (in-process protocol conformance lifecycle test).
The in-process test in #3875 dispatches the JSON-RPC envelope directly through `mcpHandler` with mocked deps. It does NOT exercise the transport layer: there is no real HTTP listener, no SSE upgrade, no session resumability under reconnect.
Build a separate suite that:
- Spins up a real HTTP listener bound to `mcpHandler` (or the default `handler`) on a localhost port.
- Exercises the streamable-HTTP `POST` → SSE upgrade path that long-lived MCP clients use.
- Replays a session by re-connecting with a previously-emitted `Last-Event-ID` header and asserts the server resumes at the correct event offset.
- Round-trips the `Mcp-Session-Id` header across reconnect — emit it on `initialize`, drop the socket, re-connect with the same session ID, and assert subsequent calls share session-scoped state where applicable.
Why this is a distinct PR from the in-process lifecycle suite: the transport layer needs a real HTTP runtime, real socket I/O, and likely Vercel-edge fixtures that the in-process tests deliberately avoid (they run fast against a mocked deps bundle). Bundling the two surfaces would have made #3875 ship-slow and review-noisy.
Follow-up to #3875 (in-process protocol conformance lifecycle test).
The in-process test in #3875 dispatches the JSON-RPC envelope directly through `mcpHandler` with mocked deps. It does NOT exercise the transport layer: there is no real HTTP listener, no SSE upgrade, no session resumability under reconnect.
Build a separate suite that:
Why this is a distinct PR from the in-process lifecycle suite: the transport layer needs a real HTTP runtime, real socket I/O, and likely Vercel-edge fixtures that the in-process tests deliberately avoid (they run fast against a mocked deps bundle). Bundling the two surfaces would have made #3875 ship-slow and review-noisy.