Add stdio-mode SIGTERM observability handler (#156)

[obj-p]

Summary

Closes the question raised in #156 by establishing — through local repro — that the daemon already exits promptly on SIGTERM. Adds a small observability hook so any future recurrence is self-diagnosing.

Investigation findings (issue #156)

PR #146 landed a 5s-poll + SIGKILL band-aid in MCPTestServer.stop(). CI then went 8/8 green with zero SIGKILL escalations, meaning the daemon really does exit within the poll window — so the 1200s wedge wasn't the daemon being slow to die. Local repro confirms this:

Scenario	SIGTERM-to-exit
Bare previewsmcp serve (no MCP traffic), 10×	~5ms
Bare with MCP initialize, 10×	~5ms
Foundation Process + Pipe() mirroring MCPTestServer, 10×	~70ms
MacOSMCPTests.hotReloadStructural (full preview state)	52ms
Full MacOSMCPTests × 5 iterations (30 SIGTERM cycles)	53–60ms median, 0 escalations

The three issue-listed hypotheses:

• Use _NSGetExecutablePath for daemon self-path resolution (#100) #153's _NSGetExecutablePath change — ruled out by code analysis. Only on the daemon-mode spawn path and the preview_build_info tool. Not on the stdio shutdown path.
• Detect daemon version mismatch and transparently restart (#142) #144's retry-handshake holds locks — ruled out. Lives in DaemonClient, used only by CLI clients, not MCPTestServer.
• NSApplication runloop swallows SIGTERM — ruled out by repro. Daemon dies in 4-60ms in every loaded condition I tested.

The 1200s wedge was inside Foundation's Process.waitUntilExit() Mach-port path on the test-host side. The polling band-aid sidesteps it. The daemon side is healthy.

Change

Add a signal-safe SIGTERM handler in runStdio(). Behavior:

• Writes previewsmcp stdio: received SIGTERM, exiting via signal-safe write(2) from a StaticString buffer.
• Calls _exit(0) — no AppKit teardown, no libdispatch dependency.

Deliberately not the daemon-mode DispatchSource(... queue: .main) pattern. That path is coupled to NSApplication's runloop, and queue starvation under load was the only remaining live hypothesis for the original wedge. Stdio mode has no on-disk state to clean up before exit (no PID file, no socket), so signal-thread _exit(0) is correct.

The single observable side effect is the stderr breadcrumb. If a future shutdown wedge recurs, the presence/absence of this line in the per-instance log partitions "daemon ignored signal" from "Foundation Process wedged on the test-host side."

Test plan

• swift build clean
• swift test --filter MacOSMCPTests — 7/7 pass, exit latency unchanged (50-60ms per stop)
• Bare-spawn SIGTERM verified: rc=0 (clean handler exit), breadcrumb in stderr
• Breadcrumb appears in per-instance daemon log immediately before [stop ...] process exited after SIGTERM
• CI green