Fix concurrent sendMessage race by retrying on FAIL_NON_SERIALIZED

Replace tryEmitNext (fail-fast) with emitNext + busyLooping(10ms)
in ManagedStdioClientTransport.sendMessage().

The unicast sink's SinkManySerialized wrapper returns FAIL_NON_SERIALIZED
when two threads call tryEmitNext concurrently. busyLooping retries the
CAS spin instead of immediately failing, making concurrent sends safe.
The contention window is microseconds (single CAS operation), so the
10ms duration is just a generous upper bound.

Before: 18/20 test repetitions fail
After:  20/20 pass

Author: AbbasNS

src/main/java/org/sonarsource/sonarqube/mcp/client/ManagedStdioClientTransport.java

@@ -139,9 +139,15 @@ private void handleIncomingErrors() {
 
   @Override
   public Mono<Void> sendMessage(McpSchema.JSONRPCMessage message) {
-    return outboundSink.tryEmitNext(message).isSuccess() 
-      ? Mono.empty() 
-      : Mono.error(new RuntimeException("Failed to enqueue message for '" + serverName + "'"));
+    try {
+      // busyLooping retries on FAIL_NON_SERIALIZED (concurrent tryEmitNext from another thread)
+      // instead of failing immediately. The contention window is microseconds (single CAS),
+      // so the spin resolves almost instantly; the duration is just an upper bound.
+      outboundSink.emitNext(message, Sinks.EmitFailureHandler.busyLooping(Duration.ofMillis(10)));
+      return Mono.empty();
+    } catch (Sinks.EmissionException e) {
+      return Mono.error(new RuntimeException("Failed to enqueue message for '" + serverName + "'", e));
+    }
   }
 
   private void startInboundProcessing() {