StdioClientTransport: Inbound Scheduler and Error Scheduler threads are locked on Windows

從 io.modelcontextprotocol.client.transport.StdioClientTransport 開始，重點關注 Inbound Scheduler、Error Scheduler 和 closeGracefully 方法，然後檢查隨附的 Windows 執行緒傾印，以找出遭到阻塞的讀取操作。在 Windows 上重現 Spring AI Filesystem Demo，並驗證關閉作業會終止 Java 程序，而不會留下遭鎖定的 scheduler 執行緒。

Bug description
Two threads, Inbound Scheduler and Error Scheduler, remain locked forever (at java.io.FileInputStream.readBytes native call) in io.modelcontextprotocol.client.transport.StdioClientTransport after the graceful shutdown is completed using closeGracefully method.

Looks like a Windows specific issue with native I/O calls. The problem is observed when running on Windows. No problems with Linux environment.

The thread dump is attached.
dump_jdk17.txt
See "pool-2-thread-1" and "pool-5-thread-1" dumps.

Environment
Windows 11 Enterprise
mcp-core 0.17.1
Spring AI 2.0.0-SNAPSHOT
JDK Temurin 17.0.14 (also tried Amazon Corretto 21.0.5)

Linux Behavior
Works fine under Ubuntu 24.04 and JDK Temurin 21.0.10

Steps to reproduce

• Run the steps from the Spring AI Filesystem Demo example on Windows.
• The Java application process is not terminated as expected.

Expected behavior
The Java process terminates after running the Spring AI Filesystem Demo example.

Possible solution
On Windows, use daemon threads for inbound and error schedulers

private ThreadFactory daemonThreadFactory = runnable -> {
		Thread t = new Thread(runnable);
		t.setDaemon(true);
		return t;
	};

if (isWindows) {
    this.inboundScheduler = Schedulers.fromExecutorService(Executors.newSingleThreadExecutor(daemonThreadFactory), "inbound");
    this.errorScheduler = Schedulers.fromExecutorService(Executors.newSingleThreadExecutor(daemonThreadFactory), "error");
}

Tried this solution locally. It resolves the termination issue. But the graceful shutdown logic in io.modelcontextprotocol.client.transport.StdioClientTransport#closeGracefully should be revised as well.