docs(lobe-chat): resolve the TTS env-vs-UI question — it is a split

Verified against the running image, not docs. TTS goes browser -> Lobe's
server route (backend)/webapi/tts/openai -> the OpenAI provider, whose
server base URL is OPENAI_PROXY_URL, so the endpoint inherits the gateway
and reaches ext-tts with no extra config (route probes 401, i.e. exists).
But there are ZERO process.env.*TTS*/*AUDIO*/*SPEECH* vars: voice, model,
response_format and enable live in a client-side store (bundle key
TTS_SETTING_KEY='tts'), UI-configured per browser.

So against the manageable-or-scriptable criterion: the load-bearing part
(endpoint) is env-scriptable and wired; the rest is a one-time UI setup,
not a maintenance surface. response_format=mp3 is the one thing not
env-forceable -- verify at first use or eat 23.5MB/turn WAV.

stacks/lobe-chat/README.md

@@ -22,17 +22,33 @@ that objection still holds. (Its recorded *secondary* objection — the empty-`t
 400 against vLLM — is now moot: the `strip_empty_tools` callback covers the normal
 API path and only failed to protect LiteLLM's own built-in playground.)
 
-## ⚠️ The open question this deploy exists to answer
+## ANSWERED — Lobe TTS is a SPLIT: endpoint env-driven, voice/model/format UI-only
 
-**Is Lobe's TTS configurable by ENV, or only through the settings UI?** That is the
-operator's deciding criterion — manageable/scriptable by an agent — and it is
-unresolved. Open WebUI has dedicated `AUDIO_TTS_ENGINE` / `AUDIO_TTS_OPENAI_API_BASE_URL`
-/ `AUDIO_TTS_MODEL` / `AUDIO_TTS_VOICE`. Lobe documents a **shared** `OPENAI_PROXY_URL`,
-which *should* carry TTS because LiteLLM serves `/v1/chat/completions` and
-`/v1/audio/speech` on the same base — but that is inference, not verification.
+Resolved 2026-08-16 against the running image (`.next` server bundle + route probe),
+not docs:
 
-If it turns out UI-only, the real choice is: 1.8 GB with genuine scriptability, or
-143 MB with click-ops. That is an operator call, not an agent one.
+- **There is a server-side route** `(backend)/webapi/tts/openai/route.js` — TTS goes
+  browser → Lobe server → the **OpenAI provider**, whose server-side base URL is
+  `OPENAI_PROXY_URL`. So the TTS *endpoint* inherits the gateway and reaches `ext-tts`
+  with no extra config. (Probing the route bare returns 401 — it exists and wants the
+  browser's provider payload — not 404.)
+- **No `process.env.*TTS*` / `*AUDIO*` / `*SPEECH*` vars exist at all.** Voice, model,
+  `response_format`, and the enable-toggle live in a **client-side settings store**
+  (bundle key `TTS_SETTING_KEY = 'tts'`), configured in Settings, per browser. There is
+  no `AUDIO_TTS_*` equivalent to Open WebUI's.
+
+**Verdict against the operator's "manageable OR scriptable" criterion:** the
+load-bearing part (endpoint → gateway → ext-tts) IS env-scriptable and already wired;
+voice/model/format are a **one-time UI setup per browser**, not a maintenance surface.
+That is "manageable", which was acceptable. Harmless-by-now footnotes: a voice
+mis-click can't 404 (tts-dev aliased the full OpenAI set), and an unknown `model`
+routes to the gateway default. The ONE thing not forceable by env is
+`response_format: mp3` — if Lobe defaults to WAV you get 23.5 MB/turn; verify at first
+use and set it in the UI.
+
+Trade recorded for the record: Open WebUI has dedicated `AUDIO_TTS_*` env vars (fully
+scriptable) at 1,825 MB; Lobe is endpoint-env + UI-cosmetic at 143 MB. Operator chose
+to proceed with Lobe.
 
 ## TTS — verified with tts-dev, 2026-08-16