feat(live): improve conversation turn-taking and response pacing

[rich7420]

Summary

Live conversations had three rough edges: Hawky jumped in during short mid-sentence pauses, spoke replies that ran too long for voice, and — after being interrupted — sometimes resumed the very reply the user had just cut off. This PR fixes all three, plus a startup-latency issue found along the way. Independent of #123; whichever merges second takes a trivial context rebase in LiveSessionStore.

• Interrupted replies stay interrupted (WS transport). Stopping playback on user speech was not enough: audio deltas still in flight for the cancelled reply would restart playback mid-sentence. The interruption now latches that reply, and its remaining audio is dropped until the next reply begins (released on response.created and on the interrupted reply's own terminal event; cleared on stop/reconnect — so it can never swallow the next reply's audio and can never get stuck). Decision logic is extracted into pure helpers with 13 unit tests.
• Turn detection understands sentence breaks. New sessions default to OpenAI's semantic_vad (eagerness auto), which decides end-of-turn from what is being said instead of a fixed 500ms silence window — the direct fix for replies barging into thinking pauses. Existing installs keep their stored mode: a persisted server_vad cannot be distinguished from a deliberate choice, so it is never silently flipped (users can switch in Live settings).
• Spoken replies sized for voice. The concise persona now gives the model concrete guidance — "1–3 short sentences per turn; for lists or steps, give one item and offer to continue" — kept byte-identical between the bundled copy and the gateway prompt registry that overrides it at runtime. A ~800-token output cap (config-overridable) backs the prompt up, applied via the post-connect session.update on both transports; the client-secret mint schema rejects that field, so a unit-tested invariant keeps it off both mint paths.
• Camera comes up with the connection, not after it. The camera pipeline used to start dead last — behind the mic warm-up and the WebRTC connect including its up-to-8s session-config ack — despite being fully independent (frames buffer until the data channel is ready). It now starts concurrently and joins at the original point, so failure handling is unchanged. The effective session config is passed explicitly so per-session overrides cannot be bypassed, and a new recording mic mark in the Start-timing diagnostics makes the remaining startup costs measurable.

Design notes and the follow-up plan live in docs/live-turn-taking.md.

Validation

• bunx tsc --noEmit clean; bun run test: 4750 pass / 5 skip (3 failures are pre-existing flaky watcher-timeout tests on the main tip: the suite passes 39/0 in isolation and a parallel full run exits 0).
• iOS device build: BUILD SUCCEEDED, zero Swift errors; simulator: drop-latch and settings-default suites TEST SUCCEEDED (17 XCTest + 64 Swift Testing, including the 13 new latch tests).
• Invariants spot-checked on the final tree: latch engage/drop/release/clear sites; semantic_vad payload emitted on both transports; token cap present on session.update and absent from both mint bodies; persona copies byte-identical.

Limitations / Follow-ups

1. Existing installs keep their stored turn-detection mode and must switch to Semantic manually in Live settings (deliberate — silently flipping a stored value could override a real user choice).
2. The WebRTC-transport barge-in rework (the app currently mutes the mic while the assistant speaks), echo hardening, and interruption truncation need on-device A/B testing and ship separately (plan in docs/live-turn-taking.md).
3. The boot-context RPC still runs serially before connect; it is the next startup-latency candidate if camera bring-up still feels slow.