feat(daemon): on-demand lifecycle — lazy start + idle auto-stop — and a 20-30 session benchmark #53

Problem

The daemon today is manually managed: daemon install switches the status line to shared mode and the daemon runs until stopped. For users with a variable number of sessions this is all-or-nothing:

• few sessions → a resident ~100 MB node process for a handful of renders per day is not worth it;
• many sessions → shared mode is a large win (feat(daemon): opt-in shared-mode install, status/recovery UX, benchmarks and acceptance gates (#19) #50 acceptance: 80.7% CPU reduction per render vs one-shot at the gate; warm shared renders 16.9–46.8 ms CPU).

Users should not have to flip this switch by hand as their session count changes through the day.

Proposed design (single mechanism, no session counting)

Counting Claude Code sessions is unreliable (there is no public session registry). The request stream the daemon already sees is the real signal:

1. Lazy start (client-side). The IPC client, on discovering no live daemon, starts one and connects. The cold-start lock from feat(daemon): coordinated lifecycle — cold-start lock, stale recovery, upgrade restart (#17) #47 already serializes concurrent starts. The first render after an idle period pays the cold start (~hundreds of ms, once per idle period).
2. Idle auto-stop (daemon-side). The daemon exits by itself after N minutes with zero requests (default ~10, configurable). Busy periods keep it alive naturally — no thresholds, no observers.
3. Opt-in semantics unchanged. On-demand behavior activates only when shared mode is installed; one-shot users never spawn anything.
4. Recovery paths from feat(daemon): coordinated lifecycle — cold-start lock, stale recovery, upgrade restart (#17) #47 (stale socket, upgrade restart, bounded retries) apply as-is to lazy starts.

Effect: "few sessions" → the daemon serves the burst, then quietly disappears (zero resident RAM); "many sessions" → it stays warm the whole time and caches pay off.

Benchmark gap: 20–30 concurrent sessions

The current acceptance gates measure small warm scenarios. Add a bench scenario matching real usage:

• 20–30 concurrent clients hitting the daemon, mixed cold/warm caches (different repos/transcripts);
• measure CPU/render and p95 latency vs 20–30 concurrent one-shot renders;
• record results in docs/ next to daemon-19-bench.md.

Acceptance

• With shared mode installed and zero activity for N minutes, no ccstatusline daemon process remains; the next render transparently restarts it.
• During a 20–30 client burst the daemon stays alive and serves everything (no 503 storm beyond the documented bounded queue).
• Bench table added; numbers recorded in docs/.
• bun test and bun run lint green; tests for the lazy-start race, the idle timeout, and opt-in gating.