unified-mcp-server: daemon lifecycle — start-on-demand, lock/port file, restart #411

Part of #408. Depends on the HTTP transport.

Why

A singleton has to outlive the session that started it, and must not become a way to lose every provider at once.

What

• start-on-demand: first client starts the daemon if it is not listening
• a port/lock file so clients find it and two starts cannot race
• survives session exit; restarts cleanly after a crash
• an explicit stop/status command

The risk to design against

This turns N independent per-session processes into one shared process. Today a wedged MCP server costs one session its provider tools; afterwards it costs every session on the machine. Blast radius goes up even as memory goes down, so restart and failure behaviour is the load-bearing part of this issue, not an afterthought.

Acceptance

• second client reuses the running daemon rather than starting a second
• daemon survives the exit of the session that spawned it
• stale port/lock file after a hard kill does not wedge the next start
• documented stop/status path