[jpurnell]

Summary

StatelessHTTPServerTransport keys per-request state — the response waiter and the
originating HTTP context — on the client-chosen JSON-RPC id. JSON-RPC ids are
client-scoped, and this transport is explicitly multi-client, so concurrent POSTs with
colliding ids are legal and common (most clients start their id sequence at 1). Two
concurrent requests sharing an id currently:

• overwrite the first request's response waiter → the first POST's continuation is
  displaced and never resumed; that HTTP exchange hangs forever and the continuation leaks
  (StatelessHTTPServerTransport: concurrent requests sharing a JSON-RPC id overwrite each other's response waiter (hang + continuation leak) #254); and
• overwrite the first request's HTTP context (httpRequestContexts[id]) → a handler
  processing one client's request can read another client's Authorization header via
  Server.currentHandlerContext.httpContext (StatelessHTTPServerTransport keys per-request HTTP context by client-chosen JSON-RPC id — concurrent clients with colliding ids can observe each other's HTTPRequest (including Authorization) #265).

Fix

Reject a request whose id is already in flight with HTTP 409 / JSON-RPC -32600
instead of silently displacing the first request. The in-flight context map is populated
synchronously before any suspension, so it is a reliable "id in flight" marker on the
transport actor. This isolates every in-flight exchange and closes both the hang/leak and
the cross-client context disclosure.

This is the minimal, non-behavioral-change-to-ctx.id fix. Transparent support for
concurrent colliding ids (via internal id remapping) is a larger change tied to the
stateless-core semantics in SEP-2575 (#245) and is intentionally out of scope here.

Tests

Adds testCollidingInFlightRequestIDsRejected:

• the duplicate returns promptly with 409 (no hang),
• the first request's httpRequestContext is never overwritten (auth stays isolated),
• the first request still completes normally with its own response,
• only the first request is ever dispatched to the server.

All existing HTTP-server transport and handler-context tests pass unchanged; full MCP
suite green (552 tests).

Fixes #254
Fixes #265

[varun06]

Hi @jpurnell, thank you for this contribution, and for #268 as well.

We don't think rejecting duplicate in-flight ids with 409 is the right approach. JSON-RPC ids only need to be unique per client, so two different clients legitimately using id: 1 at the same time would be rejected. #298 instead gives each HTTP exchange a private internal id, which fixes #254 and #265 without rejecting valid requests.

We plan to close this PR once #298 is merged. If you think a case here isn't covered by #298, please comment and we'll make sure it's handled.