Sessions keep running across navigation: turn liveness + write-ahead persist

The bug: answering a quiz and navigating away mid-turn, then returning,
re-prompted the same question. Root causes: (1) the answer was durable only
at onFinish — every mid-turn view read the stale pre-answer record;
(2) the server had no notion of a turn in flight; (3) remount treated the
stale record as current, with no re-attach path. Worse, the stale dock let
the quiz be answered again, racing two turns into a last-writer-wins
saveMessages clobber.

Fix (four pieces):
- Write-ahead persist in chat-handler: the request body IS the client's
  canonical state — saved to disk BEFORE the stream starts. The answer is
  durable the instant the request arrives; crashes recover via the existing
  mount continuation.
- Turn liveness registry (src/server/turn-liveness.ts): in-memory chatId →
  in-flight map with a TTL leak guard; beginTurn rejects concurrent turns
  (409) so one turn ever owns a chat. endTurn runs in onFinish AFTER
  persistTurn, so pollers that see not-in-flight always read a finished
  record; a turn-start failure clears the registry (no lockout).
- GET /api/chats/[id] reports turnInFlight; the chat page passes
  initiallyInFlight to the client.
- Client re-attach (components/chat.tsx): while in flight, busy shimmer +
  composer gated + mount continuation suppressed; poll /api/chats/[id] until
  the turn finishes, then syncFromServer adopts the completed transcript.
  Stop stays local-stream only (a server turn has no client request to
  abort).

Verified by scripted-model tests: concurrent turn 409 + registry lifecycle,
write-ahead durability mid-turn, failed-turn lockout guard.

src/server/turn-liveness.ts

@@ -0,0 +1,42 @@
+/**
+ * Server-side turn liveness: which chats currently have a teacher turn in
+ * flight. The missing half of "sessions keep running in the background" —
+ * together with the write-ahead persist in chat-handler, a returning client
+ * can tell "the teacher is mid-turn — don't resurrect, don't start anything"
+ * apart from "the record IS current".
+ *
+ * In-memory BY DESIGN: a process restart clears it, so there are no stale
+ * flags to clean up — a crashed turn recovers via the write-ahead record +
+ * mount continuation on the next visit. The TTL is a leak guard for the
+ * pathological case where onFinish never fires (it runs even on aborts);
+ * chat turns are minutes at most, so 30 minutes is far on the safe side.
+ */
+
+const inFlight = new Map<string, number>(); // chatId → startedAt (epoch ms)
+const MAX_TURN_MS = 30 * 60_000;
+
+/**
+ * Mark a turn as starting. Returns false if one is already running for the
+ * chat — the caller rejects the request (only one turn may own a chat).
+ */
+export function beginTurn(chatId: string): boolean {
+	if (isTurnRunning(chatId)) return false;
+	inFlight.set(chatId, Date.now());
+	return true;
+}
+
+/** Mark the chat's turn as finished (runs in onFinish, aborted or not). */
+export function endTurn(chatId: string): void {
+	inFlight.delete(chatId);
+}
+
+/** True while the chat's turn is in flight; lazily evicts stale entries. */
+export function isTurnRunning(chatId: string): boolean {
+	const since = inFlight.get(chatId);
+	if (since === undefined) return false;
+	if (Date.now() - since > MAX_TURN_MS) {
+		inFlight.delete(chatId);
+		return false;
+	}
+	return true;
+}