docs(frank-tts): retire the 5.5 s cold-voice claim everywhere it still lived

PR #15 corrected the engine's page, the research brief's law bullet and the
warmer's header, but the retired ladder had six more homes: both quadlet files
("6.2-8.0 s… 0.5 ms", "~6-8 s each", "paying the 5.5 s cold decode"),
`scripts/frank-tts-engine.env` (the whole law paragraph and the WARM_TEXT note),
`scripts/frank-tts.env`, the [[Frank TTS]] troubleshooting row that told an
operator to expect ~5.5 s, the research brief's consequences paragraph, and one
test comment.

All re-keyed to what was measured on the deployed container 2026-10-18: the
first synthesis of a freshly registered voice costs 1,883 ms against 1,226-1,283
ms afterwards, so the warm pass buys about 0.6 s — and the reason it exists at
all, which the pages never led with, is that the registry is memory-only: without
the hook every voice name is a 400 until somebody synthesizes. The trial's dated
worklog entry stays as written; the correction points at it.

No behavior change: comments, unit lore and docs only, so no cfhash move and no
image rebuild.

serverAppConfigs-docs/Research/Local TTS and Voice Cloning.md

@@ -328,9 +328,11 @@ a live stream mid-sentence.
 **Chosen: arm A, 1.7 B talker, resident `tts-server` in a `frank-tts-engine`
 container, with `TTS_BACKEND=llama-tts-cli` kept in the repo as the rollback.**
 Three consequences are configuration, not opinion: the unit **boot-warms every
-voice** (5.5 s cold first byte otherwise), it **does not pin a cpuset** casually
-(threads are `hardware_concurrency()/2`, no flag), and every pack registers with
-the **WAV** because the engine rejects a lone embedding.
+voice** — the registry is memory-only, so an unwarm'd name is a 400 and the first
+synthesis otherwise costs about 0.6 s more than the ones after it, as corrected
+above —, it **does not pin a cpuset** casually (threads are
+`hardware_concurrency()/2`, no flag), and every pack registers with the **WAV**
+because the engine rejects a lone embedding.
 
 Two follow-ups stay open on purpose, and neither blocks the deploy: