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.

scripts/open-notebook.env

@@ -38,11 +38,12 @@
 # LINE, not per episode: one episode is dozens of POSTs to /v1/audio/speech
 # (the app synthesises each speaker turn separately and concatenates the clips
 # with ffmpeg afterwards), and a CPU engine takes single-digit seconds for a
-# line, with the tail of a long turn well past the 300 s default. 600 matches
-# SHIM_TIMEOUT in scripts/frank-tts.env — the shim's own per-request ceiling —
-# so open-notebook never abandons a synthesis frank-tts is still finishing. An
-# abandoned request does not cancel the engine process; it just leaves the
-# episode stuck in "generating" while the audio arrives.
+# line, with the tail of a long turn well past the 300 s default. 660 sits one
+# round-trip OUTSIDE SHIM_TIMEOUT=600 in scripts/frank-tts.env — the shim's own
+# per-request ceiling — so a frank-tts give-up arrives as frank-tts's error and
+# not as open-notebook abandoning a synthesis still in flight. An abandoned
+# request does not cancel the engine process; it just leaves the episode stuck in
+# "generating" while the audio arrives.
 #
 # THE SCRIPTWRITER. ESPERANTO_LLM_TIMEOUT is the app's own default (180 s), kept
 # visible beside the TTS number because both belong to one podcast run: the
@@ -87,7 +88,7 @@ TTS_BATCH_SIZE=1
 OPEN_NOTEBOOK_WORKER_MAX_TASKS=1
 
 # Timeouts: see "THE TTS CLOCK" and "THE SCRIPTWRITER" above.
-ESPERANTO_TTS_TIMEOUT=600
+ESPERANTO_TTS_TIMEOUT=660
 ESPERANTO_LLM_TIMEOUT=180
 
 # Heavy extraction runtimes stay OFF, which is also what keeps boot fast: each