fix(mcp): stop sharing a single MCP Server instance across HTTP/SSE sessions

[clitnak]

Bug

mcp/src/tools/server.ts wires both the streamable-HTTP (/graph_mcp) and legacy SSE (/sse) routes to a single, module-level graphServer singleton:

export const graphServer = new Server({ name: "Stakgraph", ... });
export const server = new MCPHttpServer(() => graphServer); // always returns the same instance

The MCP SDK's Server/Protocol only supports one active transport at a time. Calling connect() again on the same instance throws:

Error: Already connected to a transport. Call close() before connecting to a new
transport, or use a separate Protocol instance per connection.

(or, on older @modelcontextprotocol/sdk versions from before modelcontextprotocol/typescript-sdk#1405 was fixed, it silently corrupts the previous session instead of throwing at all — same root cause, different symptom.)

Impact: the very first client to connect to a long-lived stakgraph-mcp process works fine. Every connection after that — a second question, a second user, even a k8s readiness/liveness probe hitting /sse — permanently breaks the MCP endpoint until the process is restarted. This reproduces reliably in any deployment where the process stays up between requests (e.g. a Kubernetes Deployment), which is the norm outside of quick local dev loops where frequent restarts mask it.

This regression traces back to #1371 ("refactor: consolidate mcp server code"). Before that PR, mcp/src/handler/server.ts's MCPHttpServer took a serverFactory: () => McpServer and actually called it fresh per session — the consolidation accidentally collapsed that into a factory closure that always returns the same object.

Fix

• server.ts: replace the exported graphServer singleton with a createGraphServer() factory that builds a fresh Server (with the same request handlers / lifecycle hooks) on every call. MCPHttpServer already expects exactly this shape (serverFactory: () => MCPServerLike) and already key's its internal session map correctly — it was just being handed a closure that returned the same instance every time.
• sse.ts: same fix, plus a related bug this was masking — currentTransport was a single shared variable, so independent of the Server singleton issue, /messages could only ever route to whichever SSE client connected last, silently misdirecting every other concurrent client's messages. This now tracks transports in a sessionId-keyed map (using SSEServerTransport's own generated sessionId, echoed back via the standard ?sessionId= query param on /messages), matching the pattern MCPHttpServer already uses correctly for the streamable-HTTP route.

No behavior change for the common single-client/short-lived-process case; this only changes behavior once a second session is attempted against the same running server (which now works, instead of throwing/misrouting).

Testing

Verified the change is syntactically valid (esbuild parse-check on both files, no full local build available in my environment). I don't have a way to run the full test suite here — happy to address CI feedback if anything else needs adjusting.