build(web): pull in threadnet-call-embedded 0.19.2-threadnet.10

Way B from #0054: the AI filter attaches to the local microphone track after
publication, with its own AudioContext on just that track - no webAudioMix, no
processor key in the capture defaults in any state. The feature gate stays
closed; a single test client opts in via two localStorage keys. For everyone
else this build behaves identically to .9.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

.gitlab-ci.yml

@@ -7,6 +7,41 @@
 # - webpack braucht ~4 GB Heap -> NODE_OPTIONS
 # - Desktop-Build laeuft im dockerbuild-Image (rust:bullseye + node, glibc-2.31-Ziel)
 
+# --- Wann ueberhaupt eine Pipeline entsteht ------------------------------------
+# Ohne diesen Block erzeugt ein Commit, der nur docs/ anfasst, eine Pipeline mit
+# NULL Jobs - und die zaehlt in GitLab als "failed". Real passiert am 2026-08-06
+# (Pipelines 203 und 204): zwei Doku-Commits, zweimal rot, nichts kaputt.
+#
+# Der Grund liegt an der needs-Kette: web laeuft wegen changes: nicht, und
+# desktop_linux/desktop_windows haengen per needs daran - damit faellt die ganze
+# Pipeline in sich zusammen, auch die manuellen Jobs ohne needs.
+#
+# ⚠️ Warum das keine Kosmetik ist: In gitops/CLAUDE.md ist die rote Pipeline die
+# ALARMANLAGE fuer die TURN-Rotation ("es gibt keinen separaten Reminder"). Rot,
+# das nichts bedeutet, gewoehnt einem das Hinsehen ab.
+#
+# Preis: Nach einem reinen Doku-Commit entsteht keine Pipeline von selbst. Damit
+# die manuellen Wartungsjobs (desktop_image, windows_provision) trotzdem
+# erreichbar bleiben, laesst die Regel CI_PIPELINE_SOURCE == "web" durch - eine
+# ueber "Run pipeline" in der Oberflaeche gestartete Pipeline entsteht immer.
+.pfade_mit_pipeline: &pfade_mit_pipeline
+  - apps/**/*
+  - packages/**/*
+  - patches/**/*
+  - scripts/**/*
+  - pnpm-lock.yaml
+  - pnpm-workspace.yaml
+  - .gitlab-ci.yml
+
+workflow:
+  rules:
+    - if: $CI_COMMIT_TAG =~ /^v/
+    - if: $CI_PIPELINE_SOURCE == "schedule"
+    - if: $CI_PIPELINE_SOURCE == "web"
+    - if: $CI_COMMIT_BRANCH
+      changes: *pfade_mit_pipeline
+    - when: never
+
 stages:
   - build
   - package
@@ -82,14 +117,8 @@ web:
       when: never
     # Pushes nur, wenn build-relevante Pfade betroffen sind - Doku-Commits kosten nichts
     - if: $CI_COMMIT_BRANCH
-      changes:
-        - apps/**/*
-        - packages/**/*
-        - patches/**/*
-        - scripts/**/*
-        - pnpm-lock.yaml
-        - pnpm-workspace.yaml
-        - .gitlab-ci.yml
+      # derselbe Anker wie im workflow-Block oben - zwei Listen wuerden driften
+      changes: *pfade_mit_pipeline
   variables:
     NODE_OPTIONS: "--max-old-space-size=6144"
     CI_PACKAGE: "true"
@@ -123,8 +152,31 @@ docker_web:
     DOCKER_BUILDKIT: "1"
   script:
     - echo "$REGISTRY_PASSWORD" | docker login rohana.axion1337.de -u "$REGISTRY_USER" --password-stdin
+    # Ein veroeffentlichtes Release darf sich nicht rueckwirkend aendern.
+    #
+    # Am 2026-08-09 hat das Force-Push umgezogener Tags (History-Anonymisierung)
+    # drei Release-Pipelines neu gestartet - darunter v0.4.0. Ohne diese Sperre
+    # haette der Lauf das laengst veroeffentlichte Image aus altem Code mit
+    # heutigen Basis-Images und Abhaengigkeiten neu gebaut und ueberschrieben.
+    # Dass es damals nicht passierte, lag nur daran, dass die geschuetzten
+    # Registry-Variablen in dem Moment nicht verfuegbar waren - Glueck, nicht
+    # Absicht (ThreadNet-Web#14).
+    #
+    # Ein Tag ist hier kein Verwaltungseintrag, sondern ein Build-Ausloeser. Wer
+    # einen Tag verschiebt, loest einen Build aus, ob er will oder nicht. Deshalb
+    # Unveraenderlichkeit erzwingen statt auf Vorsicht zu hoffen.
+    - |
+      if docker manifest inspect "$IMAGE:$CI_COMMIT_TAG" >/dev/null 2>&1; then
+        echo "FEHLER: $IMAGE:$CI_COMMIT_TAG existiert in der Registry bereits."
+        echo "Ein veroeffentlichtes Release wird nicht ueberschrieben."
+        echo "Gewollt? Dann das Image bewusst aus der Registry entfernen oder eine"
+        echo "neue Version taggen - siehe ThreadNet-Web#14."
+        exit 1
+      fi
     - docker build -f apps/web/Dockerfile -t "$IMAGE:$CI_COMMIT_TAG" -t "$IMAGE:latest-ci" .
     - docker push "$IMAGE:$CI_COMMIT_TAG"
+    # latest-ci bleibt bewusst ueberschreibbar - der Tag bezeichnet "der neueste
+    # Stand", nicht eine Version, und traegt deshalb kein Versprechen.
     - docker push "$IMAGE:latest-ci"
 
 # Einmalig/selten: Build-Image fuer den Desktop-Build (rust:bullseye + node + tcl/sqlcipher,

AGENTS.md

@@ -0,0 +1,33 @@
+# AGENTS.md — ThreadNet-Web
+
+> **Die Gruppenregeln sind kanonisch im `management`-Repo:**
+> [`AGENTS.md`](https://git.lab/axion1337.chat/management/-/blob/main/AGENTS.md)
+> — von außerhalb des Labs über den Gitea-Mirror lesbar:
+> `https://rohana.axion1337.de/sorb/management`. Dort stehen Repo-Topologie und
+> Mirror-Regeln, das Kanban-Framework (Status-Labels, WIP-Limit 2, ADR-Pflicht),
+> Deploy-Übergabe und AAR-Verfahren, Secrets-Handhabung und die
+> Karpathy-Leitlinien. Sie gelten für **jede** Session in diesem Repo.
+> Hier steht nur, was zusätzlich für dieses Repository gilt.
+
+## Was dieses Repo ist
+
+Fork von **Element Web/Desktop** (Basis `1.12.17`) für axion1337.chat.
+
+⚠️ **`README.md` und der Großteil von `docs/` sind unverändertes Upstream-Material** und
+beschreiben diesen Fork ausdrücklich **nicht**. Wer sich danach richtet, übersieht jede
+Anpassung.
+
+## Der eine Ort, der zählt
+
+**[`docs/axion1337-fork.md`](docs/axion1337-fork.md)** ist die vollständige Liste dessen, was
+dieser Fork gegenüber Upstream ändert — und zugleich die **Portier-Checkliste** für jedes
+Upstream-Upgrade: dort stehen die kritischen Dateien, an denen die Merge-Reibung entsteht.
+
+**Jede Änderung am Fork gehört dort hinein.** Eine Anpassung, die nur im Code steht, geht beim
+nächsten Rebase verloren — genau dafür existiert die Datei.
+
+## Bauen & Ausrollen
+
+Image wird in die Registry auf `rohana.axion1337.de` publiziert; die laufende Version zieht der
+Cluster über den Tag im gitops-Repo (`apps/production/`). Ein Upgrade ist deshalb zweistufig:
+erst hier rebasen und bauen, dann dort den Tag anheben.

CLAUDE.md

@@ -0,0 +1 @@
+Read AGENTS.md — the canonical instruction file for this repository. All rules live there.

apps/desktop/axion1337/config.json

@@ -1,5 +1,6 @@
 {
   "brand": "aXion1337.Chat",
+  "bug_report_endpoint_url": "local",
   "branding": {
     "auth_header_logo_url": "vector-icons/512.png",
     "logo_link_url": "https://axion1337.chat"

apps/web/package.json

@@ -125,7 +125,7 @@
         "@babel/preset-react": "^7.12.10",
         "@babel/preset-typescript": "^7.12.7",
         "@casualbot/jest-sonar-reporter": "2.7.0",
-        "@sorb/threadnet-call-embedded": "0.19.2-threadnet.5",
+        "@sorb/threadnet-call-embedded": "0.19.2-threadnet.10",
         "@element-hq/element-web-playwright-common": "workspace:*",
         "@fetch-mock/jest": "^0.2.20",
         "@jest/globals": "^30.2.0",

docs/axion1337-fork.md

@@ -53,6 +53,94 @@ statt 755 committet (nicht ausführbar); (2) der `matrix-js-sdk#develop`-Git-Ref
 `pnpm-lock.yaml` war veraltet (fehlte `src/oidc/authorize.ts`, das `apps/web` importiert).
 Beide behoben.
 
+## 4. Merge-Reibung: was ein Upstream-Update wirklich kostet
+
+*Arbeitspaket 3 aus ThreadNet-Web#7. Gemessen am 2026-08-06, nicht geschätzt.*
+
+### Die unangenehme Grundlage zuerst
+
+**Dieses Repo enthält keine Upstream-Historie.** Element Web 1.12.17 wurde am
+2026-05-10 als kompletter Baum importiert — und zwar in `3da3635`, zusammen mit dem
+ersten eigenen Feature im selben Commit. Davor liegt nur ein `Initial commit` mit
+zwei Dateien.
+
+Daraus folgt das Wesentliche: **es gibt keinen gemeinsamen Vorfahren mit
+`element-hq/element-web`.** Ein `git merge upstream/develop` ist nicht möglich; mit
+`--allow-unrelated-histories` erzwungen, kollidiert praktisch jede Datei. Wer „mal
+eben Upstream nachziehen" sagt, meint in diesem Repo also: neuen Upstream-Stand
+beschaffen und unsere Änderungen darauf neu auftragen.
+
+Das ist der Grund, warum die Zahl unten überhaupt zählt — sie ist der Aufwand jedes
+Updates.
+
+### Unser Delta: 102 Dateien, davon 12 kritische
+
+`git diff --name-only 3da3635..main`:
+
+| Menge | Bereich | Konfliktrisiko |
+|---|---|---|
+| 46 | CI/Build (`.github/`, `.gitlab-ci.yml`, `dockerbuild/`) | gering — eigene Strecke, Upstreams Workflows brauchen wir nicht |
+| 22 | Config, Lockfiles, Upstream-Varianten | mittel — `pnpm-lock.yaml` konfliktet immer, wird aber regeneriert |
+| 13 | Web-Assets (`apps/web/res/`) | gering — meist eigene Dateien |
+| 4 + 3 | eigene Icons und `apps/desktop/axion1337/` | **keins** — kein Upstream-Pendant |
+| **12** | **Upstream-Quellcode** | **hier entsteht die Arbeit** |
+
+### Die 12 Dateien, und warum sie angefasst wurden
+
+**Branding (5)** — flach, gut isolierbar:
+
+- `apps/web/src/SdkConfig.ts` — Defaults für `brand`, `welcome_background_url`, `desktopBuilds`
+- `apps/web/src/vector/index.html` — `<title>`, Favicon-Link, PWA-Namen
+- `apps/web/src/async-components/structures/ErrorView.tsx` — Logo der Fehlerseite
+- `apps/web/src/components/views/settings/tabs/user/HelpUserSettingsTab.tsx` — Attribution + Danksagung
+- `apps/web/src/i18n/strings/en_EN.json` — einzelne Strings
+
+**ClamAV-Client-Scanning (7)** — tief in der Medien-Pipeline:
+
+- `apps/web/src/ContentMessages.ts`, `utils/ContentScanner.ts`, `utils/DecryptFile.ts`
+- `apps/web/src/components/views/messages/MImageBody.tsx`, `MAudioBody.tsx`
+- `apps/web/src/viewmodels/message-body/FileBodyViewModel.ts`, `VideoBodyViewModel.ts`
+
+### Nicht der Umfang entscheidet, sondern die Art des Eingriffs
+
+Gemessen in geänderten Zeilen nehmen sich beide Gruppen wenig: **ClamAV ~130 Zeilen,
+Branding ~104**. Der größte Einzelpatch ist sogar Branding
+(`HelpUserSettingsTab.tsx`, 71 Zeilen). Wer nur zählt, hält beide für gleich teuer.
+
+Sie sind es nicht, und der Grund ist die Art des Eingriffs:
+
+- **Branding-Patches stehen am Rand.** Ein zusätzlicher Default in `SdkConfig.ts`,
+  ein `<link>` im `<head>`, ein `<li>` in einer Settings-Liste. Wird die Datei
+  umgebaut, sieht man sofort, wo das eigene Stück wieder hin muss.
+- **ClamAV-Patches stehen mittendrin** — in Entschlüsselungs- und Fehlerpfaden der
+  Medien-Pipeline, verschränkt mit Upstream-Logik. Ein geänderter Kontrollfluss
+  bedeutet nicht „Konflikt lösen", sondern „neu verstehen".
+
+⚠️ **Und der eigentliche Haken: `viewmodels/`.** Element baut die Medien-Anzeige
+gerade auf MVVM um (`docs/MVVM.md`; v1 ist dort bereits als deprecated markiert —
+der Umbau läuft also schon in zweiter Runde). `FileBodyViewModel.ts` und
+`VideoBodyViewModel.ts` gab es in älteren Ständen gar nicht. Unsere Änderung darin
+ist mit je 6 Zeilen winzig — aber wenn Upstream diese Dateien verschiebt, umbenennt
+oder auflöst, entsteht **kein Konflikt**: die Zeilen sind einfach weg, und Git meldet
+nichts. Das ist gefährlicher als ein Konflikt, weil es stillschweigend passiert.
+
+Praktische Folge: Nach einem Upstream-Update ist an ClamAV nicht die Merge-Ausgabe
+maßgeblich, sondern ein **Funktionstest** — eine verschlüsselte Datei senden und eine
+abgelehnte empfangen. Steht so auch in Abschnitt 2.
+
+### Was daraus für künftige Änderungen folgt
+
+1. **Erst prüfen, ob es die Konfiguration schon kann.** Auth-Logo, `logo_link_url`
+   und `brand` liefen ohne Rebuild über die ConfigMap; das Call-Widget wurde
+   vollständig über `VITE_PRODUCT_NAME` umbenannt, ohne eine einzige Quelldatei.
+   Jede so vermiedene Datei ist eine, die beim Update nicht kollidiert.
+2. **Eigene Datei schlagen geänderte Datei.** `apps/desktop/axion1337/` und eigene
+   Assets kosten beim Merge nichts.
+3. **Wenn Upstream-Code sein muss: einen Kommentar mit `ThreadNet-Fork:` und der
+   Begründung dazu.** Beim Neuauftragen auf einen neuen Stand ist die Frage nie
+   „was steht hier", sondern „warum stand das da" — und die beantwortet sonst
+   niemand mehr.
+
 ## Repo-Topologie (seit 2026-07-31)
 
 **Kanonisch ist `git.lab/axion1337.chat/ThreadNet-Web`** (Homelab-GitLab, nur im Lab

pnpm-lock.yaml

@@ -617,8 +617,8 @@ importers:
         specifier: ^5.0.0
         version: 5.2.1(encoding@0.1.13)(webpack@5.106.2)
       '@sorb/threadnet-call-embedded':
-        specifier: 0.19.2-threadnet.5
-        version: 0.19.2-threadnet.5
+        specifier: 0.19.2-threadnet.10
+        version: 0.19.2-threadnet.10
       '@stylistic/eslint-plugin':
         specifier: ^5.0.0
         version: 5.10.0(eslint@8.57.1)
@@ -5003,8 +5003,8 @@ packages:
   '@sinonjs/fake-timers@15.1.1':
     resolution: {integrity: sha512-cO5W33JgAPbOh07tvZjUOJ7oWhtaqGHiZw+11DPbyqh2kHTBc3eF/CjJDeQ4205RLQsX6rxCuYOroFQwl7JDRw==}
 
-  '@sorb/threadnet-call-embedded@0.19.2-threadnet.5':
-    resolution: {integrity: sha512-u2TG7i82ibkpHSH/s6xA4Q6BTJqITdYWyrVieTiRwnm2Z+SCn/GmPK8JZIp/uSnpMrl9619yp/6vDVtpDJsKZg==, tarball: https://rohana.axion1337.de/api/packages/sorb/npm/%40sorb%2Fthreadnet-call-embedded/-/0.19.2-threadnet.5/threadnet-call-embedded-0.19.2-threadnet.5.tgz}
+  '@sorb/threadnet-call-embedded@0.19.2-threadnet.10':
+    resolution: {integrity: sha512-E/gtIkqZL5X07mDShsgcAFmd6QAVud6nAUBeYO6++js9o8wdvGKMUbaJMKlNAlsQDMvKv57R1L37Jyi746EbMg==, tarball: https://rohana.axion1337.de/api/packages/sorb/npm/%40sorb%2Fthreadnet-call-embedded/-/0.19.2-threadnet.10/threadnet-call-embedded-0.19.2-threadnet.10.tgz}
 
   '@standard-schema/spec@1.1.0':
     resolution: {integrity: sha512-l2aFy5jALhniG5HgqrD6jXLi/rUWrKvqN/qJx6yoJsgKhblVd+iqqU4RCXavm/jPityDo5TCvKMnpjKnOriy0w==}
@@ -17632,7 +17632,7 @@ snapshots:
     dependencies:
       '@sinonjs/commons': 3.0.1
 
-  '@sorb/threadnet-call-embedded@0.19.2-threadnet.5': {}
+  '@sorb/threadnet-call-embedded@0.19.2-threadnet.10': {}
 
   '@standard-schema/spec@1.1.0': {}