fix(stdio): process messages concurrently to prevent deadlocks

[blackwell-systems]

Motivation and Context

Fixes #572

StdioServerTransport.processReadBuffer() invokes each message handler sequentially: _onMessage.invoke(message) blocks the loop until the handler returns. A long-running tool call (e.g., one that waits for elicitation) blocks all subsequent messages, including pings, progress notifications, and the elicitation response itself. This creates deadlocks for any bidirectional communication pattern.

As noted by @rnett in #572:

This creates deadlocks for any bidirectional communication, which is now easy with ClientConnection. Even for ping.

Fix

Launch each message handler in its own coroutine via scope.launch instead of awaiting it inline. The ReadBuffer parsing remains sequential (required for correct JSON-RPC framing), but handler execution is now concurrent.

This is the minimal transport-level fix. A prior attempt (#610) placed concurrency in AbstractTransport but was closed due to complications with transports that already handle concurrency (SSE server). This PR scopes the change to StdioServerTransport only.

Test changes

The error-handling parameterized test (should continue processing messages after handler throws) needed a brief delay(100) after secondMessageProcessed.await() because the error callback from the first message's coroutine now fires asynchronously on IODispatcher rather than synchronously in the processing loop.

How Has This Been Tested?

All 17 StdioServerTransportTest cases pass, including the 3 parameterized error-handling variants.

Types of changes

• Bug fix (non-breaking change which fixes an issue)

Checklist

• I have read the MCP Documentation
• My code follows the repository's style guidelines
• New and existing tests pass locally
• I have added appropriate error handling