docs: Document simulcast middle layer and H.264 codec switch for calls

docs/TASKS.md

@@ -55,8 +55,10 @@ verankert. Was in dieser Session erledigt wurde:
    und danach committed. Nebenbei: `matrixRTC`-Authorisation-Service OOM-Fix (20Mi→128Mi).
 
 ### Offene Punkte
-- **VP9-Retry**: Root Cause des Call-Ausfalls isolieren (Browser-Konsolen-Repro nötig), bevor
-  wieder versucht wird — siehe Backlog "Element Call Enhancement".
+- **VP9-Retry**: vermutete Ursache jetzt bekannt (LiveKit nutzt SVC für vp9/av1, Fork-Code
+  setzt aber immer Simulcast-Layer) — braucht einen Code-Fix in `buildPublishOptions()`
+  (`src/livekit/options.ts`) bevor erneut versucht wird. Stattdessen H.264 probiert (siehe
+  unten) — läuft gut, kein SVC-Risiko, hardwarebeschleunigt auf mehr Geräten.
 - **`ThreadNet-Web` Build-Bug**: `scripts/docker-link-repos.sh`/`docker-package.sh` nicht
   ausführbar committet + veralteter `matrix-js-sdk#develop`-Pin im Lockfile blockiert
   vollständigen Neu-Build des Web-Forks. Noch nicht gefixt, User hat noch nicht final

docs/deployment-guides/04-element-customization.md

@@ -57,9 +57,16 @@
   LiveKits eigener Empfehlung für Mensch-zu-Mensch-Calls. Bewusst **kein** server-seitiges
   ML-Noise-Cancellation (siehe `docs/TASKS.md` Backlog).
 - **Incident (2026-07-28)**: Erster Versuch mit erzwungenem `video_codec: vp9` hat Calls
-  komplett kaputt gemacht (kein Bild/Ton). Sofort zurückgerollt, dann ohne erzwungenen Codec
-  (Standard VP8) mit denselben Auflösungswerten neu deployed — funktioniert, live bestätigt.
-  VP9 vorerst zurückgestellt (Backlog).
+  komplett kaputt gemacht (kein Bild/Ton). Sofort zurückgerollt. Vermutete Ursache: LiveKit
+  nutzt für vp9/av1 SVC statt klassischem Simulcast, `buildPublishOptions()` im Fork setzt
+  aber immer Simulcast-Layer — Code-Fix nötig, bevor vp9 erneut versucht wird (Backlog).
+- **720p-Zwischen-Layer ergänzt** (`simulcast_layers`) — ohne eigene Definition fiel die
+  Übertragung bei kleinsten Netzwerkschwankungen direkt von 1440p auf blockiges 360p, jetzt
+  sanftere Abstufung über 720p.
+- **H.264 statt VP8** (2026-07-28) — nutzt wie VP8 klassisches Simulcast (kein SVC-Risiko wie
+  bei VP9), zusätzlich auf vielen Geräten (v.a. iOS/Safari) hardwarebeschleunigt. Live
+  verifiziert: 7 von 8 Video-Tracks liefen über H.264, 1 fiel sauber auf den VP8-Backup-Codec
+  zurück (kein Ausfall). Deployed als `v0.2.3-elementcall-h264`.
 - Deployt als `rohana.axion1337.de/sorb/threadnet-web:v0.2.1-elementcall-noquotavp9` — nur
   der `/app/widgets/element-call/`-Ordner im bestehenden `v0.1.0`-Image ausgetauscht, da
   `ThreadNet-Web` einen vorbestehenden Build-Bug hat (siehe unten).