docs: LiveKit-Token-Minting-Migrationsplan (apiSecret raus aus Client)

Fertiger Umsetzungsplan fuer den offenen M0-Punkt: Token-Endpoint am
Dashboard-Server mintet LiveKit-JWTs server-seitig (Matrix-whoami-Auth,
stdlib-HMAC), Client holt nur das JWT. Braucht echten Call-Test -> nur Plan.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

PROGRESS.md

@@ -13,6 +13,28 @@ Schritt (und beim Abbruch mitten im Schritt den Zwischenstand). Format:
 
 ---
 
+## 2026-07-04 – LiveKit-Token-Minting: Migrationsplan geschrieben (Prep, kein Code)
+
+**Erledigt:** Für den offenen M0-Punkt „LiveKit-Token server-seitig minten"
+(letzter Client-eingebetteter Secret nach der Diagnose-Entkopplung) den fertigen
+Umsetzungsplan `docs/LIVEKIT_TOKEN_MIGRATION.md` geschrieben – gegen den echten
+Client-Code (`livekit_token.dart`, `livekit_call_manager.dart:154`) und die echte
+Pi-Konfig (`livekit.yaml`, `server.py`, Continuwuity `whoami`). Kern: Token-Route
+`POST /api/livekit-token` am bestehenden Dashboard-Server, die den Matrix-Access-Token
+per `whoami` prüft und daraus die LiveKit-Identität ableitet (kein Spoofing), JWT
+per stdlib-HMAC mintet (kein neues Paket); Client holt nur noch das fertige JWT und
+`apiSecret` verschwindet aus dem App-Code. Analog zum bewährten
+`SQLCIPHER_MIGRATION.md`-Muster.
+
+**Offen/Nächster Schritt:** Umsetzung braucht echten Call-Test auf einem Gerät
+(Calls „heilig", auf dem Pi kein GUI) – daher bewusst nur der Plan, kein Code.
+Danach Secret-Rotation zusammen mit einem Release. Verbleibende M0-Secrets
+(Admin-Token, Gitea-, Giphy-Token) brauchen Bernds Konten-Zugriff.
+
+**Stolperfallen:** Keine – reine Doku.
+
+---
+
 ## 2026-07-04 – Admin-Token aus dem Client entfernt (E2EE-Diagnose entkoppelt)
 
 **Erledigt:** Den kritischsten Teil des Secret-Befunds (k) wirklich behoben, statt