fix(open-notebook): size the TTS clock outside frank-tts's own ceiling

The env file first landed with ESPERANTO_TTS_TIMEOUT equal to SHIM_TIMEOUT=600.
Equality is a race: both budgets expire at the same instant, so the case the
number existed to prevent — the worker abandoning a synthesis frank-tts is still
finishing — is exactly what happens on the tail of a long line. Nested budgets
go inside-out, which is the rule scripts/frank-tts.env states for its own
LLAMA_TIMEOUT; the client waits one round-trip longer than the server, so a
frank-tts give-up arrives labelled as frank-tts's error. 660.

The seam's assertion moves from equality to `>` for the same reason, and now
also holds ESPERANTO_LLM_TIMEOUT under upstream's 600 s web-UI patience — above
it the failure surfaces as a UI timeout with no name on it. The scriptwriting
number itself stays at the app's 180 s default: frank-zealot answers an outline
or a transcript well inside it, which corrects the earlier commit message's
claim that both timeouts were raised past upstream's 300 s.

serverAppConfigs-docs/Dankclaw/Open Notebook.md

@@ -88,9 +88,9 @@ None of it blocks anything: model rows are added **by name** ("If a model isn't
 
 ## The CPU guard, and why both numbers are 1
 
-Defaults are `TTS_BATCH_SIZE=5` and `OPEN_NOTEBOOK_WORKER_MAX_TASKS=5` (`docs/5-CONFIGURATION/environment-reference.md:129-130`) — five parallel synthesis requests from five parallel jobs. frank-tts spawns an engine process per request (about 8 GiB resident, 8 threads, from the frank-tts CPU trial of 2026-10-18; `scripts/frank-tts.env` pins `LLAMA_TTS_THREADS=8`), on a machine that also serves frank-dragoon and frank-zealot. Five of those is ~40 GiB and forty threads competing with two LLM endpoints for the same cores. `scripts/open-notebook.env:86-87` sets both to 1: one episode at a time, one voice line at a time. Upstream's own guidance is the same direction ("Set 1 for a local model on a single GPU", "Lower it … for rate-limited or single-threaded TTS servers").
+Defaults are `TTS_BATCH_SIZE=5` and `OPEN_NOTEBOOK_WORKER_MAX_TASKS=5` (`docs/5-CONFIGURATION/environment-reference.md:129-130`) — five parallel synthesis requests from five parallel jobs. frank-tts spawns an engine process per request (about 8 GiB resident, 8 threads, from the frank-tts CPU trial of 2026-10-18; `scripts/frank-tts.env` pins `LLAMA_TTS_THREADS=8`), on a machine that also serves frank-dragoon and frank-zealot. Five of those is ~40 GiB and forty threads competing with two LLM endpoints for the same cores. `scripts/open-notebook.env:87-88` sets both to 1: one episode at a time, one voice line at a time. Upstream's own guidance is the same direction ("Set 1 for a local model on a single GPU", "Lower it … for rate-limited or single-threaded TTS servers").
 
-The clock next to it: `ESPERANTO_TTS_TIMEOUT=600` (`:90`) is patience **per dialogue line**, not per episode — a three-minute episode is dozens of separate POSTs, and the tail of a long turn on a CPU engine goes past the 300 s default. 600 matches `SHIM_TIMEOUT` in `scripts/frank-tts.env`, frank-tts's own per-request ceiling, so the worker never abandons a synthesis the shim is still finishing; an abandoned request does not cancel the engine process, it just strands the episode in "generating".
+The clock next to it: `ESPERANTO_TTS_TIMEOUT` (`:91`) is patience **per dialogue line**, not per episode — a three-minute episode is dozens of separate POSTs, and the tail of a long turn on a CPU engine goes past upstream's 300 s default. It is set to **660, one round-trip outside `SHIM_TIMEOUT=600`** in `scripts/frank-tts.env` (frank-tts's own per-request ceiling): nested budgets go inside-out — the same rule that file states for `LLAMA_TIMEOUT` — so a frank-tts give-up arrives labelled as frank-tts's error instead of the worker's own timeout, and re-measuring frank-tts cannot silently strand this number below it. An abandoned request does not cancel the engine process; it only strands the episode in "generating".
 
 ## Secrets, and the difference between blank and unset
 

serverAppConfigs-docs/log.md

@@ -2345,8 +2345,13 @@ every restart since the cutover.
   to `TTS_BATCH_SIZE=5` × `OPEN_NOTEBOOK_WORKER_MAX_TASKS=5` — a five-way
   self-DoS. Both are pinned to `1` in `scripts/open-notebook.env`, and the
   worker knob is only real because the image's own supervisord expands
-  `${OPEN_NOTEBOOK_WORKER_MAX_TASKS:-5}` (`supervisord.conf:25`). Both
-  `ESPERANTO_*` timeouts go above upstream's 300 s for CPU synthesis.
+  `${OPEN_NOTEBOOK_WORKER_MAX_TASKS:-5}` (`supervisord.conf:25`). The TTS clock
+  goes to **660 — one round-trip outside** frank-tts's own `SHIM_TIMEOUT=600`, so
+  a shim give-up reads as the shim's error rather than the worker's; the seam
+  asserts the direction (`>`) against the frank-tts env instead of restating a
+  number. `ESPERANTO_LLM_TIMEOUT` stays at the app's 180 s default: frank-zealot
+  answers an outline or a transcript well inside it, and upstream says to keep it
+  under 600 so a slow call fails with a name on it.
 - **What a credential needs in order to exist:** `OPEN_NOTEBOOK_ENCRYPTION_KEY`
   must be set before the UI can save *any* provider credential, and
   `OPEN_NOTEBOOK_PASSWORD` must stay **absent** to remain auth-off — the app