docs: Document VP9 incident and v0.2.1 fix for Element Call fork

docs/TASKS.md

@@ -244,8 +244,14 @@
   - Fork: `rohana.axion1337.de/sorb/threadnet-call` (basiert auf `emmick4/element-call:livekit`,
     das den noch nicht gemergten Upstream-PR element-hq/element-call#3736 enthält —
     config-driven `media_quality`, keine Custom-Logik nötig)
-  - Defaults angehoben: Video bis 1440p/60fps (VP9, ~8 Mbps), Screen-Share 1440p/30fps (~6 Mbps).
+  - Defaults angehoben: Video bis 1440p/60fps (~8 Mbps), Screen-Share 1440p/30fps (~6 Mbps).
     Das sind Startwerte, keine harten Limits — Nutzer können in den Settings weiter hochdrehen.
+  - **Incident (2026-07-28)**: Erster Deploy (`v0.2.0`, mit `video_codec: vp9` erzwungen) hat
+    Calls komplett kaputt gemacht (kein Bild/Ton), obwohl LiveKit-Server-Logs den
+    Codec-Regression-Fallback auf VP8 als erfolgreich zeigten — Root Cause nicht abschließend
+    isoliert. Sofort auf `v0.1.0` zurückgerollt, dann `v0.2.1` ohne erzwungenen Codec (Standard
+    VP8) mit denselben 1440p/60fps-Werten deployed und vom Nutzer live bestätigt: funktioniert.
+    VP9-Präferenz vorerst fallengelassen, siehe Backlog.
   - Rauschunterdrückung: nur clientseitige WebRTC-Standardtoggles (echoCancellation/
     noiseSuppression/autoGainControl), kommt kostenlos mit derselben PR. **Bewusst kein**
     server-seitiges ML-Noise-Cancellation (LiveKit Agents + DTLN/RNNoise) — laut LiveKits
@@ -266,6 +272,8 @@
     unabhängig von diesem Fix, blockiert aber jeden zukünftigen vollständigen Rebuild.
   - Backlog: MAL-basierte Noise-Cancellation (LiveKit Agents + self-hosted DTLN/RNNoise) als
     experimentelle Idee, falls später gewünscht — kein etablierter Pfad für Conferencing.
+  - Backlog: VP9-Codec-Präferenz erneut versuchen, sobald PR #3736 upstream gemerged/gereift
+    ist oder Root Cause des Ausfalls isoliert wurde (Browser-Konsolen-Repro nötig).
 
 ### Database Hardening
 - [ ] **External/Dedicated PostgreSQL Deployment**