Add a Windows implementation of StdioTransport

[onetamer]

Problem

StdioTransport is gated on canImport(Darwin) || canImport(Glibc) || canImport(Musl) — it drives stdin/stdout through POSIX non-blocking file-descriptor I/O (fcntl/O_NONBLOCK) — so it compiles out on Windows and the SDK offers no stdio transport there. Windows is where stdio matters most right now: Claude Desktop's claude_desktop_config.json validates stdio (command) entries only.

Approach

An #elseif os(Windows) arm of the same file provides a public actor StdioTransport: Transport speaking the same wire contract — newline-delimited JSON-RPC frames on standard input/output — over Foundation's FileHandle, which Windows Foundation implements:

• Reads run on a dedicated OS thread (Thread.detachNewThread), so a blocking stdin read never parks a cooperative-pool thread. Lines split on LF; a trailing CR is stripped in case a Windows-side client writes CRLF.
• Sends append the LF delimiter and write synchronously; write failures surface as MCPError.transportError.
• EOF on stdin finishes the message stream, matching the POSIX implementation.

The public surface matches the POSIX actor (connect/disconnect/send/receive + logger), minus the FileDescriptor-typed initializer parameters, which have no Windows equivalent — the Windows initializer takes only the optional Logger.

Verification

• swift build on macOS: green (the POSIX arm is untouched; the Windows arm is inactive).
• On Windows 11 ARM64 (Swift 6.3.3): this implementation is extracted nearly verbatim from a production MCP server (CopyBucket's copybucket-mcp.exe, shipping since 2.0.2) where it runs the stdio loop under real agent clients — Claude Desktop and Codex CLI — including initialize, tools/list, and tool calls with multi-hundred-KB results.

Notes

• Windows builds of the MCP target also need the EventSource platform-guard fix (companion PR Fix Windows builds: guard EventSource usage in HTTPClientTransport #279); the two are independent diffs in different files.
• Related: StdioTransport.send() still interleaves concurrent sends under EAGAIN backpressure — #252 was closed without a merged fix #263 (send interleaving under EAGAIN backpressure) is a POSIX-arm concern; on the Windows arm, sends are actor-serialized and the synchronous FileHandle write does not tear frames.