fix(server): Windows socket read/write fails with GetLastError(87)

[TheRefreshCNFT]

Windows compatibility fixes

Five fixes that get NullHub running correctly on Windows 10/11 with Zig 0.15.2.

---

1. Server socket I/O — ws2_32 recv/send (server.zig, net_compat.zig)

Problem: NullHub's HTTP server crashes immediately on Windows:
error.Unexpected: GetLastError(87): The parameter is incorrect.
std.os.windows.zig:648:53 in ReadFile
std.net.zig:2325:36 in read
server.zig:339:35 in handleConnection

Zig 0.15.2's std.net.Stream.read/write uses NtReadFile/NtWriteFile internally, which fail on sockets — Windows requires ws2_32.recv/ws2_32.send for socket I/O.

Fix: Adds net_compat.zig with a thin platform-aware compat layer (streamRead, streamWrite, streamWriteAll). All socket paths in server.zig go through it. No-op on non-Windows. Same class of fix as nullclaw/nullclaw#550.

---

2. Health check socket I/O — same compat layer (supervisor/health.zig)

Problem: The supervisor health probe has the same NtReadFile issue — stream.read/writeAll in health.zig also crash on Windows sockets.

Fix: Health check now uses net_compat.streamRead and net_compat.streamWriteAll, consistent with the server fix.

---

3. Binary path missing .exe on Windows (core/paths.zig)

Problem: Paths.binary() constructs paths like ~/.nullhub/bin/nullclaw-standalone — without the .exe suffix, the binary is never found on Windows and the instance fails to start.

Fix: Appends .exe on builtin.os.tag == .windows, no change on other platforms.

---

4. channel launch mode expands to channel start (core/launch_args.zig)

Problem: When an instance is configured with launch_mode: "channel", Hub passes nullclaw channel to the process — which prints usage and exits. The runnable command is nullclaw channel start.

Fix: buildLaunchArgs detects a bare channel token and appends start, making the mode actually supervisable. Includes test coverage.

---

5. Skip HTTP health checks for non-server launch modes (api/instances.zig)

Problem: Only agent mode was exempted from HTTP health probes. Modes like gateway and channel expose WebSocket/gateway traffic — not an HTTP health endpoint — so health probes would always fail, causing the supervisor to repeatedly mark instances as unhealthy.

Fix: Flips the logic: only serve mode gets HTTP health checks. All other modes (agent, gateway, channel, or any future non-HTTP mode) are supervised by process-alive checks only (port=0). No component names hardcoded.

---

Testing

Built and tested on Windows 10 x64, Zig 0.15.2:

• /health → {"status":"ok"}
• /api/instances → valid JSON
• Managed nullclaw instance starts and stays running under Hub supervision
• No GetLastError(87) crashes

Related: nullclaw/nullclaw#317, nullclaw/nullclaw#550