mcpdo: run the daemon test suites on Windows by porting the harness to named pipes #2922

Problem

mcpdo's Windows daemon path has never been run by a test. Production code already uses a named pipe on win32 (getDaemonSocketPath in clients/mcpdo/src/daemon/paths.ts returns \\.\pipe\mcp-conn-<hash>, and clients/mcpdo/src/daemon/client.ts handles the pipe path when locating the token file). But the daemon test harness was written for a Unix domain socket:

• suites bind or poll <dir>/mcpdod.sock directly. Windows refuses that with EACCES, and the tests then time out waiting on the daemon.
• teardown waits for the socket file to vanish. A pipe never appears there, so a live daemon keeps the temp dir open and rmSync fails with EBUSY.
• some assertions assume POSIX premises (0700 directories, the sun_path limit).

#2748 (PR #2906) therefore skips 127 mcpdo tests on win32 (unixDaemonOnly in clients/mcpdo/__tests__/helpers/platform.ts). It also turns off mcpdo's per-file 90% coverage threshold on Windows only (clients/mcpdo/vitest.config.ts), because the daemon modules fall below it there. The new windows CI job is green, but it doesn't show that the daemon works on Windows.

Expected

• The daemon test helpers derive the endpoint from getDaemonSocketPath instead of a hard-coded .sock file, and tear down a named-pipe daemon cleanly on Windows.
• The suites gated by unixDaemonOnly run on the windows CI job. Only cases that assert genuinely POSIX-only behaviour stay skipped, each with its reason at the site.
• mcpdo's per-file 90% threshold is enforced on Windows again, and the win32 carve-out in clients/mcpdo/vitest.config.ts is removed.

Verification has to come from the windows CI job; maintainers develop on macOS.