docs(frank-tts): what makes a locally built voice image stale, and what the warm text must survive

Three pages, all from faults found this session:

- `LLM/deployment.md` gains "Locally built images": which images have no
  registry digest, what the `cfhash` skip is for, why it must cover every COPY'd
  file (the silent shape: build skipped, /health green, old code serving), and
  the base-image half of the law — the engine's `useradd`, because the pinned
  ubuntu:24.04 has no `adduser`.
- `Dankclaw/Frank TTS Engine.md` troubleshooting gains the two lines an operator
  actually needs: every voice cold on a fresh boot with a hand-run hook
  succeeding (= `WARM_TEXT` arrived quoted, `podman exec … env | grep WARM_TEXT`
  proves it), and a 502 from the façade beside a 200 `/health` from the engine
  (model loaded ≠ voices registered). The stale-warmer row is re-keyed to the
  new rebuild rule.
- `Dankclaw/Voice Packs.md` step 4 was wrong: it told the next agent to restart
  the engine *instead of* the warm hook because the hook "only registers packs it
  has not seen". It registers every pack on every run and the engine replaces a
  name it already holds — `tools/tts-server.cpp:148` at the pinned commit:
  "Re-registering a name replaces the previous entry." A restart is what an
  engine bump needs (the registry is memory-only), never worse, only slower.
- `Dankclaw/Frank TTS.md` deploy command re-keyed to `./scripts/deploy.sh
  dankclaw --service frank-tts`, the way it is actually deployed; the raw
  `deploy-remote.sh` form is plumbing.

serverAppConfigs-docs/LLM/deployment.md

@@ -116,6 +116,34 @@ On a later ordinary deployment, a service remains pending only while its
 recorded revision differs from the checkout and the planner still finds a
 change in that service's inputs.
 
+## Locally built images
+
+`build_compose_image` in `scripts/deploy-remote.sh` builds the images that have
+no registry digest — `comfyui-rocm`, `franksdank/loki`, `franksdank/alloy` and
+the voice pair `franksdank/frank-tts` / `franksdank/frank-tts-engine` — and
+**skips** the build when a `cfhash` label on the installed image matches a hash
+it computes from the checkout now. That skip is what keeps the engine's
+ten-minute `git clone --recursive` off every re-deploy, so the rule has to be
+honest about what the image bakes:
+
+- The hash covers the `Containerfile` **plus the files its `COPY` lines pull
+  in**, named as `extra=(…)` in each case arm. Hashing the `Containerfile`
+  alone was wrong in practice: editing `dankclaw/voiceservice/app.py` or
+  `tts-engine-warm.sh` left the label matching, `podman build` never ran, and
+  the redeployed container still carried the previous code while `/health`
+  answered — invisible to every gate. Corrected 2026-10-18;
+  `tests/frank_tts_engine.bats` drives the function against a stub `podman`
+  (first deploy builds, unchanged tree does not, a `COPY`'d file rebuilds).
+- A base-image assumption is part of the image's identity too. The engine's
+  runtime stage creates its unprivileged user with `useradd`, not `adduser`,
+  because the pinned `ubuntu:24.04` base ships no `adduser` — checked by
+  running the command against the digest on 2026-10-18. That failure mode is a
+  build that dies at the `RUN` line, so it is loud, unlike the stale-hash one.
+
+Both engines keep serving during a rebuild: `build_compose_image` runs after
+`install_quadlet` only for the LLM-style handlers, and the voice deploy gates on
+recorded health rather than a fixed sleep — see [[Frank TTS Engine]].
+
 ## Manual recovery
 
 If the LLM handler fails after the target pull: