Fix legacy MCP session request isolation - #7337

Approving. Two independent pieces of per-session state were being shared across concurrent requests — the ServerWebExchange (one slot in ShenyuMcpExchangeHolder per session) and the captured response (one lastSentMessage slot per transport) — and this fixes both by keying each to the request instead of the session.

What I verified:

• The fallback is genuinely preserved. getOriginExchange now tries mcpExchange.transportContext() first and only then ShenyuMcpExchangeHolder.get(sessionId), so transports that do not populate the context keep working. The two new unit tests pin both directions (context wins, holder still consulted) — good, because that ordering is the whole compatibility story.
• Leaving the old single-slot isResponseReady() in place is correct, not an oversight. I checked both remaining callers: :880 is the initialize-handshake completion check and :973 is the "is this session initialised" heuristic. Both run during session creation, where there is exactly one request in flight, so they do not need per-id correlation. Scoping the new responses map to the concurrent business-request path is the right call.
• doOnNext → doFinally matters more than it looks. A cancelled request previously left lastSentMessage populated, and that stale message is precisely what the next request on the session could read. Releasing on cancel and error, not just success, closes it.
• removeSession marking closed = true is safe across threads — closed is volatile (:1059), and sendMessage checks it before capturing, so a discarded transport stops accumulating state while another thread is mid-send.

The tests are the right kind: testConcurrentRequestsKeepExchangeAndResponseCorrelation drives eight concurrent requests through one session with a per-request marker and asserts each response carries its own id and marker — that fails on master on both counts (every callback resolves to the last-bound exchange, and the single response slot mismatches ids), so it is a real regression test rather than a restatement of the implementation.

Non-blocking

1. One map entry can outlive a cancelled request. doFinally removes responses.remove(messageId), but if the client cancels before the upstream response arrives, that remove is a no-op and the late response is then inserted and stays until removeSession or a full resetCapturedMessage(). It is one entry per cancelled in-flight request, bounded by session lifetime — but on a long-lived session with lots of client cancellations (users closing a tab mid-tool-call) it grows. Bounding the map, or recording cancelled ids so sendMessage can skip them, would close it.
2. The fallback is now silent. The old CRITICAL: No exchange found ... ERROR was replaced by a debug line in processWithExistingSession. Since falling back to the session holder is exactly the behaviour that is wrong under concurrency, a WARN there would tell operators whether the context path is actually being taken in their deployment.
3. Mono.defer(() -> session.handle(message)) before contextWrite is worth a comment: it guarantees the handler observes this request's context rather than anything captured at assembly time, and it is the sort of thing a later cleanup would remove.

Re-reviewed: isolating legacy MCP session requests and reworking the streamable HTTP transport provider is a focused fix with tests on both sides. CI is green on this head — approving.