[type: bug] Fix concurrent tools/call response correlation by message id (#7041)

[zhang-arvin]

Fixes #7041

Problem

StreamableHttpSessionTransport captured MCP framework responses in a single lastSentMessage slot guarded by responseReady. When multiple tools/call requests are processed concurrently on the same session, the response of request A can be overwritten by the response of request B, and A's resetCapturedMessage() can then wipe out the response B just wrote. This yields cross-delivered responses, empty responses, or responses with the wrong JSON-RPC id.

Fix

• Add a ConcurrentHashMap<String, JSONRPCMessage> messageResponses keyed by the JSON-RPC response id to allow per-message correlation.
• In sendMessage, keep the existing lastSentMessage/responseReady behaviour (needed by the initialization handshake) and additionally store JSONRPCResponse messages in messageResponses keyed by resp.id().
• Add getLastSentMessage(Object messageId) which looks up the correlated response when a message id is available and falls back to lastSentMessage otherwise; the no-arg getLastSentMessage() and isResponseReady() are kept for existing callers.
• waitForTransportResponse now first tries the id-correlated response and returns it with HTTP 200; when no correlated response exists it keeps the previous fallback (lastSentMessage and the synthetic success response).
• processWithExistingSession clears only the response captured for the current message id via the new resetCapturedMessage(Object messageId) overload, without disturbing the handshake-related single slot.