fix: handle concurrent sendMessage calls in StdioServerTransportProvider

[dominikozi]

Replace tryEmitNext() with emitNext() using a busy-looping retry handler in StdioMcpSessionTransport.sendMessage() to support concurrent tool call responses without crashing.

Motivation and Context

Fixes #686.
When multiple tool calls are executed concurrently on MCP server using StdioServerTransportProvider, the server crashes with RuntimeException: Failed to enqueue message. The reason is that sendMessage() used tryEmitNext() on the outbound sink, which fails immediately when another thread is concurrently emitting instead of retrying.

How Has This Been Tested?

Added shouldHandleConcurrentMessages test that sends two concurrent JSON-RPC requests with delayed responses, verifying both complete without error and are written to the output stream. The test fails on main and passes with this change. Verified all existing tests continue to pass.

Breaking Changes

None.

Types of changes

[X] Bug fix (non-breaking change which fixes an issue)

[ ] New feature

[ ] Breaking change

[ ] Documentation update

Checklist

[X] I have read the MCP Documentation

[X] My code follows the repository's style guidelines

[X] New and existing tests pass locally

[X] I have added appropriate error handling

[X] I have added or updated documentation as needed

Additional context

The fix replaces tryEmitNext() with emitNext() using Sinks.EmitFailureHandler.busyLooping(Duration.ofSeconds(1)) in StdioMcpSessionTransport.sendMessage(). This is the standard Reactor pattern for thread safe emission from multiple threads. Non retryable failures still propagate immediately as Sinks.EmissionException. I dont think this requires a documentation update.

[chemicL]

The test passes if Duration.ofSeconds(3) is provided. Preferably, instead of using delays, you'd launch a swarm of threads trying to process the messages in parallel and ensure none of them fail and all the messages are processed.