docs: correct Electron/desktop claim, add hostile-sender test result (Issue #19)

docs/deployment-guides/06-moderation-content-scanning.md

@@ -164,27 +164,49 @@ das ganze Internet wird. Fail-open bei Scanner-Fehlern, wie beim Synapse-Modul.
   `VideoBodyViewModel.ts`/`FileBodyViewModel.ts` (gleiches Muster wie die schon vorhandenen
   `DecryptError`/`DownloadError`).
 
-**Live getestet** (2026-07-29): EICAR in verschlüsseltem Gruppenraum ("testgruppe") und in
-1:1-DMs zwischen zwei echten Accounts - in beiden Fällen zuverlässig **vor dem Upload**
-blockiert. Vorher (nur Synapse-Modul) lief das durch.
+**Live getestet** (2026-07-29):
+- EICAR in verschlüsseltem Gruppenraum ("testgruppe") und in 1:1-DMs zwischen zwei echten
+  Accounts - in beiden Fällen zuverlässig **vor dem Upload** blockiert. Vorher (nur
+  Synapse-Modul) lief das durch.
+- Empfangsseite unabhängig vom Absender bestätigt: EICAR über einen echten, ungepatchten
+  Client (app.element.io) in denselben verschlüsselten Raum geschickt (simuliert einen
+  fremden/föderierten Absender ohne unseren Patch) - beim Download-/Anzeigeversuch im
+  gepatchten `ThreadNet-Web`-Client greift der Scanner zuverlässig. Beweist, dass der
+  Empfangs-Hook unabhängig vom sendenden Client funktioniert, nicht nur als Selbstschutz
+  für eigene Uploads.
 
-### ⚠️ Wichtig für zukünftige Desktop-/Electron-Forks
+### ⚠️ Wichtig für Desktop-/Electron-Builds (korrigiert, siehe Issue #44)
 
-**Dieser Fix gilt nur für den Web-Client (Browser), nicht automatisch für Element Desktop.**
+**Dieser Fix ist im Web-Client (Browser, das laufende `threadnet-web`-Container-Image)
+bestätigt live wirksam. Ob er auch im Electron-Client wirkt, hängt am tatsächlichen
+Build-Prozess - und der ist aktuell nicht automatisiert.**
 
-Element Desktop (`apps/desktop` im selben Monorepo) ist ein Electron-Wrapper, der die
-Web-App nicht selbst baut, sondern per `scripts/fetch-package.ts` ein fertiges,
-**offiziell von `element-hq/element-web` signiertes Release-Tarball** herunterlädt und in
-ein `webapp.asar` packt (`pnpm run fetch` → `pnpm run asar-webapp`). Ohne weitere Änderung
-würde ein Desktop-Build also die **unveränderte Upstream-Version** bündeln - unsere Patches
-wären nicht drin, obwohl sie im selben Monorepo liegen.
+Element Desktop (`apps/desktop` im selben Monorepo) baut die Web-App nicht selbst, sondern
+packt ein fertiges `webapp`-Verzeichnis in ein `webapp.asar`. *Woher* dieses Verzeichnis
+kommt, hängt vom Aufrufer ab:
+- **Standard-Fallback** (`pnpm run fetch <version>` ohne Artefakt): lädt ein offiziell von
+  `element-hq/element-web` signiertes Release-Tarball herunter - **Upstream, ohne unsere
+  Patches**.
+- **Mit eigenem Build** (`webapp-artifact`-Mechanismus in `build_desktop_prepare.yaml`,
+  gedacht für CI): würde unseren eigenen `apps/web`-Output übernehmen, **inklusive** aller
+  Fork-Anpassungen.
 
-**Für einen zukünftigen Desktop-Fork mit dieser Funktion**: `fetch-package.ts` akzeptiert
-bereits eine beliebige URL statt einer Versionsnummer als Override
-(`targetVersion.includes("://")`-Zweig, keine Code-Änderung nötig) - man müsste nur unseren
-eigenen `apps/web`-Build als `.tar.gz` irgendwo selbst hosten (z.B. als Gitea-Release-Asset)
-und `pnpm run fetch https://.../unser-build.tar.gz` statt der Standard-Versionsnummer
-aufrufen.
+Der zweite Weg ist im Repo als GitHub-Actions-Pipeline (`build-and-test.yaml`) angelegt,
+läuft aber **nicht automatisch** - kein registrierter Runner, und der vorgelagerte Build-Job
+checkt zudem noch `element-hq/element-web` (Upstream) statt des eigenen Forks aus, ein Rest
+der ursprünglichen Upstream-CI. Die bereits existierende Desktop-Build (mit der
+Discord-Style-Raumliste) entstand nach aktuellem Stand aus einem **manuellen, lokalen**
+Build-Durchlauf, nicht aus einem reproduzierbaren, automatisierten Prozess.
+
+**Konsequenz für heute**: die Scan-Patches sind im `ThreadNet-Web`-Fork-Code enthalten und
+würden in jedem zukünftigen (manuellen oder automatisierten) Desktop-Build aus diesem Fork
+mitkommen - sie sind aber **nicht automatisch** in einer bereits existierenden
+Desktop-Installation gelandet, ohne dass jemand den Build-Vorgang erneut manuell durchführt.
+
+Neues Backlog-Item dafür angelegt:
+[Issue #44](https://rohana.axion1337.de/sorb/axion1337.chat-gitops/issues/44) - Build-Job
+auf den eigenen Fork umstellen + funktionierenden Runner aufsetzen, damit Fork-Änderungen
+zuverlässig und automatisch auch im Desktop-Client landen.
 
 **Element X (Mobile, iOS/Android)** ist davon komplett unberührt - eigene Codebasis auf
 Basis von `matrix-rust-sdk`, kein gemeinsamer Code mit `ThreadNet-Web`. Ein Schutz dort