feat(stt): entrée texte HUD + finitions client + doc incident LLM/GPU (#19)

Regroupe le travail postérieur à la PR #18 (squash-mergée), rebasé proprement
sur main :

- HUD : composer texte (chat clavier sans micro) — {"type":"text"} →
  VoiceEngine.respond_text (hors boucle audio), lock _respond (voix ⟂ texte)
- App autonome : fenêtre app/kiosk via profil + WM class dédiés (hors Brave)
- Auto-update non destructif : `stt --update` = pipx upgrade (ne laisse plus
  l'install cassée en cas d'échec réseau)
- Terminal propre : --log-level=3 + sortie navigateur vers DEVNULL
- Docs : admin/incidents-llm-gpu.md (journal d'inférence dédié) — incident
  2026-06-19 llama-server gelé (/health OK mais génération bloquée → 502),
  + HUD README / stt.md (composer), bump 0.4.x → 0.5.1

Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>

admin/incidents-llm-gpu.md

@@ -0,0 +1,87 @@
+# Incidents LLM / GPU — llama-server (gpu-01)
+
+Journal dédié des incidents d'**inférence** : `llama-server` (ROCm / RX 6700XT sur
+gpu-01) et chaîne LLM `STT-server / Hermes → LiteLLM → llama-server`. Voir aussi
+`incidents.md` (matériel & services storage-01/k8s) et `admin/ia/llama_server.md`.
+
+---
+
+## 2026-06-19 — llama-server gelé : `/health` OK mais inférence bloquée → 502 sur tout le LLM
+
+### Symptômes
+
+- STT (HUD, **composer texte**) : `502 Server Error: Bad Gateway for url: http://stt.lab.local/v1/ask`
+- Petite **activité GPU** visible sur gpu-01 (le slot d'inférence tourne en rond)
+- STT-server : `GET /healthz` → 200, mais `POST /v1/ask` → **502**
+- llama-server `:1234` : `/health` → `{"status":"ok"}` et `/v1/models` → `qwen3-8b` listé
+  → **l'apparence est « up »**, ce qui masque la panne
+- Mais une **génération réelle ne renvoie jamais rien** : `curl /v1/chat/completions`
+  hang (45 s sans un seul token)
+- LiteLLM (storage-01) :
+  `litellm.Timeout: APITimeoutError - Request timed out. timeout value=600.0, time taken=600.0s.
+  Received Model Group=hermes-default` (après 2 retries)
+
+### Cause
+
+Le `llama-server` (gpu-01, `:1234`, `qwen3-8b`) était dans un état **wedgé** après
+~2 jours d'uptime (démarré le 2026-06-17 21:04). Les endpoints de contrôle
+(`/health`, `/v1/models`) répondaient encore, mais le **slot d'inférence ROCm était
+bloqué** (vraisemblablement une requête avortée laissée dans le slot). Chaîne du 502 :
+
+```
+HUD composer → STT-server (/v1/ask) → LiteLLM :4000 (hermes-default) → llama-server gpu-01 :1234  ← GELÉ
+```
+
+LiteLLM attend `request_timeout = 600 s`, échoue, et le STT-server renvoie 502.
+
+### Diagnostic (commandes utiles)
+
+```bash
+# 1) STT-server : confirmer que le 502 vient de lui (et pas de Traefik)
+kubectl -n ai logs <pod stt-server> --tail=50    # → "POST /v1/ask HTTP/1.1" 502
+
+# 2) LiteLLM : voir le timeout
+ssh storage-01 'journalctl -u litellm -n 40 --no-pager --output=cat'
+# → litellm.Timeout ... timeout value=600.0 ... Model Group=hermes-default
+
+# 3) llama-server : /health MENT — tester une VRAIE génération
+ssh gpu-01 'curl -s -m 30 http://127.0.0.1:1234/v1/chat/completions \
+  -H "Content-Type: application/json" \
+  -d "{\"model\":\"qwen3-8b\",\"messages\":[{\"role\":\"user\",\"content\":\"Dis bonjour. /no_think\"}],\"max_tokens\":30}"'
+# gelé (aucune sortie) = wedgé   |   réponse JSON = sain
+```
+
+### Résolution
+
+Redémarrer le service d'inférence sur gpu-01 :
+
+```bash
+ssh gpu-01 'sudo systemctl restart llama-server'
+```
+
+- L'ancienne instance gelée met **~40 s à mourir** (état `deactivating` le temps que
+  le slot bloqué se libère) — `systemctl restart` peut dépasser un timeout SSH court,
+  c'est normal ; vérifier avec `systemctl is-active llama-server` jusqu'à `active`.
+- Au redémarrage, `/v1/chat/completions` renvoie `503 {"error":"Loading model"}`
+  pendant ~30 s (rechargement du modèle en VRAM) — **normal, attendre**.
+- **Validation** : génération directe (`"Bonjour."` en ~80 ms) puis bout-en-bout
+  `POST http://stt.lab.local/v1/ask` → `{"reply":"Bonjour.","model":"hermes-default"}`.
+
+### Observations / suites (hors présent incident)
+
+- ⚠️ **Piège du health-check** : `/health` et `/v1/models` restent verts quand le
+  serveur est wedgé → un check qui ne fait **pas une vraie génération** ne voit pas la
+  panne (même angle mort que le crash-loop Qdrant en `activating`, cf. `incidents.md`).
+- **Latence cerveau** : post-restart, 30-45 s pour une réponse triviale via STT-server
+  alors que le llama-server direct est à ~80 ms → le surcoût vient du pipeline du
+  cerveau (mémoire/embeddings Qdrant `stt-memory` + LiteLLM). À investiguer séparément.
+- **Bruit LiteLLM** : `Invalid model name model=qwen3-1.7b-monitor` (profil monitor
+  Hermes) dans les logs — pré-existant, non lié à cet incident.
+
+### Prévention (pistes)
+
+- **Probe applicative** : sonde qui fait une vraie génération `/v1/chat/completions`
+  (pas seulement `/health`) → alerte si le LLM ne produit plus de tokens.
+- **Watchdog** : si LiteLLM accumule des `Timeout` sur `hermes-default`, redémarrer
+  automatiquement `llama-server` sur gpu-01.
+- Réduire le `request_timeout` LiteLLM (600 s est très long → un 502 tardif et opaque).