[jstar0]

Summary

Fixes #254.

StatelessHTTPServerTransport currently keys response waiters by the client's
raw JSON-RPC id. Because ids are scoped to each client, concurrent POSTs can
legally reuse the same id; the later request then overwrites the earlier
continuation, leaving one HTTP exchange suspended indefinitely. String and
integer ids also collide after stringification.

Changes

This change assigns a private UUID to each in-flight HTTP exchange before the
request is yielded to Server. Responses route by that private id, then restore
the client's original string or integer id before returning over HTTP.

The same exchange identity now scopes HTTP request context, while typed raw-id
aliases preserve existing direct lookups. A package-only mapping keeps
Server.currentHandlerContext.id and cancellation lookup on the original client
id without changing public transport or handler APIs. Cancellation fails closed
when multiple active exchanges make a reused wire id ambiguous.

Verification

• Added a deterministic regression that waits for two same-id requests to be in
  flight before sending either response.
• Added string/integer id, HTTP context, handler context, disconnect cleanup, and
  cancellation compatibility coverage.

swift test -v

Result: 555 tests in 40 suites passed.

Scope

• No public API or HTTP response contract changes.
• Notifications, validation, status codes, and stateless no-streaming behavior
  are unchanged.
• This does not add a waiter deadline or implement StatelessHTTPServerTransport: notifications/cancelled leaves the original POST hanging (HTTP exchange never completed) #255's cancelled-request HTTP
  completion. PR fix: StatelessHTTPServerTransport leaves the original POST hanging after notifications/cancelled (#255) #260 covers that separate path and currently lists StatelessHTTPServerTransport: concurrent requests sharing a JSON-RPC id overwrite each other's response waiter (hang + continuation leak) #254 as a
  non-goal; if it lands first, its raw-id waiter lookup will need to resolve the
  active exchange instead.

[ianegordon]

I have independently verified this PR does resolve the issue I opened, #254 . I have some low priority test improvements that can land after this PR.

I recommend landing the related PRs in the following order.
PR #264 (fixes Issue #254)
PR #260 (fixes Issue #255)

[varun06]

Hi @jstar0, thank you for this contribution. We're consolidating overlapping PRs.

#298 includes the same per-exchange isolation as this PR (fixing #254), plus the cancellation fixes for #255, so we'd like to land them together in one change. Thanks for the independent verification here.

We plan to close this PR once #298 is merged, so the fix isn't lost in between. If you think something here isn't covered by #298, please comment there or here and we'll make sure it's carried over.