ci: GitLab-Pipeline - build_embedded + manueller npm-Publish nach rohana (threadnet-call#1)

Registry-Entscheidung evidenzbasiert: das Package ist pnpm-Dependency von
ThreadNet-Webs apps/web, der Lockfile pinnt die Tarball-URL auf rohana -
Registry bleibt dort. Publish-Auth ueber CI-Variable GITEA_NPM_TOKEN statt
lokaler Klartext-.npmrc.

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

docs/axion1337-fork.md

@@ -0,0 +1,68 @@
+# threadnet-call: Fork-Anpassungen für axion1337.chat
+
+Dieses Dokument beschreibt alles, was dieser Fork gegenüber Upstream Element Call ändert. Die
+übrigen Dateien in `docs/` sind unverändertes Upstream-Material.
+
+## 1. Warum Fork von `emmick4/element-call` (Branch `livekit`)?
+
+Nicht direkt von `element-hq/element-call` geforkt, sondern von `emmick4/element-call`s
+`livekit`-Branch, weil dieser bereits den noch nicht upstream gemergten PR
+[element-hq/element-call#3736](https://github.com/element-hq/element-call/pull/3736)
+enthält - config-driven `media_quality`. Ohne diesen PR wäre eigener Custom-Code nötig gewesen,
+um Video-/Audio-Qualitätslimits pro Deployment konfigurierbar zu machen.
+
+## 2. media_quality-Defaults
+
+Konfiguriert in `vite-embedded.config.ts` (im `generateFile`-Plugin-Aufruf, der
+`media_quality` in die zur Build-Zeit gebackene `config.json` des Embedded-Packages schreibt):
+
+- Kamera: **1440p / 60fps / ~8 Mbps** (`video.max_resolution/max_framerate/max_bitrate`)
+- Screen-Share: **1440p / 30fps / ~6 Mbps**
+- 720p-Zwischen-Simulcast-Layer (`video.simulcast_layers`) - ohne diesen fiel die Übertragung
+  bei kleinsten Netzwerkschwankungen direkt von 1440p auf blockiges 360p
+- `video_codec: "h264"` (siehe Incident unten für die Begründung)
+
+Das sind Startwerte, keine harten Limits - Nutzer können in den Call-Settings weiter hochdrehen.
+
+## 3. VP9-Incident (2026-07-28) — ⚠️ nicht ohne Browser-Repro erneut versuchen
+
+Erster Versuch setzte `video_codec: "vp9"` (Commit `83db5224`). Das hat Calls **live komplett
+kaputt gemacht** (kein Bild/Ton), obwohl die LiveKit-SFU-Server-Logs den
+Codec-Regression-Fallback auf VP8 als scheinbar erfolgreich zeigten. Sofort zurückgerollt
+(Commit `f845d81e`). Vermutete Ursache: LiveKit nutzt für VP9/AV1 SVC statt klassischem
+Simulcast, aber `buildPublishOptions()` in diesem Fork setzt immer Simulcast-Layer - ein
+echter Code-Fix wäre nötig, um das aufzulösen. **Root Cause nie abschließend isoliert** (hätte
+einen Browser-Konsolen-/WebRTC-Internals-Repro gebraucht). Danach auf 720p-Zwischen-Layer +
+`h264` (klassisches Simulcast, kein SVC-Risiko, oft hardwarebeschleunigt v.a. auf iOS)
+umgestellt - live verifiziert (7/8 Tracks nativ H.264, 1 sauberer VP8-Fallback).
+
+**Nicht erneut versuchen, ohne vorher einen echten Browser-Repro zu haben.**
+
+## 4. npm-Publish zu Gitea (`@sorb/threadnet-call-embedded`)
+
+Das Embedded-Package (`embedded/web/package.json`, aktuell `0.19.2-threadnet.5`) wird zu
+Gitea's npm-Registry veröffentlicht (`https://rohana.axion1337.de/api/packages/sorb/npm/`,
+Scope `@sorb`). Der obere Versionierungs-Track hier (`0.19.2-threadnet.N`) ist unabhängig von
+den Docker-Image-Tags, unter denen das fertig gebaute Widget im gitops-Repo deployt wird (z.B.
+`v0.2.3-elementcall-h264` als `threadnet-web`-Image-Tag) - zwei getrennte Versionsschemata für
+zwei verschiedene Artefakte (npm-Package vs. Docker-Image).
+
+Der aktuelle Publish-Vorgang läuft manuell/lokal - das committete
+`.github/workflows/publish-embedded-packages.yaml` zielt noch auf `registry.npmjs.org`/
+`@element-hq`-Scope (Upstream-Konfiguration, nicht an die Gitea-Registry angepasst). Registry-
+Zugangsdaten liegen in einer lokalen, **nicht committeten** `.npmrc` - nicht Teil dieses Repos.
+
+## 5. Bewusst keine Server-seitige ML-Rauschunterdrückung
+
+Nur der client-seitige WebRTC-Standardtoggle (Echo/Noise/Gain-Suppression, aus derselben
+Upstream-PR-Linie) wurde übernommen. Bewusst **kein** LiveKit-Agents-basiertes Server-seitiges
+ML-Noise-Cancellation (z.B. selbst gehostetes DTLN/RNNoise) - LiveKits eigene Dokumentation
+beschreibt diesen Baustein als für AI-Voice-Agents gedacht, nicht für Mensch-zu-Mensch-Calls
+(kein unterstützter Weg, bereinigtes Audio an andere Teilnehmer weiterzuleiten).
+
+## Repo-Topologie (seit 2026-07-31)
+
+**Kanonisch ist `git.lab/axion1337.chat/threadnet-call`** (Homelab-GitLab) — die Kopie auf
+`rohana.axion1337.de/sorb/threadnet-call` ist ein automatischer **Push-Mirror** (Lesekopie,
+Issues, npm-Registry). **Niemals direkt nach rohana pushen** — der Mirror überschreibt
+divergente Stände.