docs(issues): #0054 — delivery path corrected, waiting on the publish act

Rolling out revealed that the first implementation would not have worked in
production: Element Call ships only as the embedded npm package, and that build
sets publicDir: false because upstream's public/ holds nothing but a favicon.
With that value everything builds, standalone works, and the filter is dead only
inside the widget — verified, not assumed.

Fixed in threadnet-call d270e0c and confirmed end to end: the widget URL resolves
to the model path and the CI artifact carries the assets, not just the local build.

Also corrects a number I gave when asking for the asset decision: the package goes
from 41 to 66 MB, not from 2 to 25 — it already contained source maps and the
crypto and vision wasm.

publish_npm stays manual by design and is sorb's to trigger.

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

docs/issues/0054-ki-geraeuschunterdrueckung-element-call.md

@@ -212,3 +212,43 @@ So baut das Repo offline und aus sich heraus. Preis: +23 MB dauerhaft (bisher gr
 - **Echter Call zu zweit** als Abnahme: der Prototyp lief gegen die eigenen Kopfhörer, nicht
   über die Leitung.
 - **Mobil** weiterhin ungeprüft (ADR-0018, bewusst).
+
+## Rollout 2026-08-16 — Auslieferungsweg korrigiert, wartet auf Publish
+
+⚠️ **Beim Ausrollen kam heraus, dass die erste Umsetzung im Produktivpfad nicht funktioniert
+hätte.** Element Call läuft **nicht** als eigenes Image. Der Weg ist:
+
+```
+threadnet-call → npm-Paket @sorb/threadnet-call-embedded → Gitea
+   → ThreadNet-Web (webpack kopiert nach webapp/widgets/element-call/) → threadnet-web-Image
+```
+
+Der Embedded-Build setzt `publicDir: false` — Upstream begründet das damit, `public/` enthalte
+nur das Favicon. Seit die Modell-Assets dort liegen, stimmt das nicht mehr. **Gemessen, nicht
+vermutet:** mit dem Upstream-Wert baut alles fehlerfrei, der Standalone-Build funktioniert, und
+**nur im Widget wäre der Filter tot** (404 auf das Modell). Genau der stille Fehlschlag, der
+ohne Prüfung des Auslieferungswegs live gegangen wäre.
+
+Behoben in `threadnet-call` `d270e0c`: `publicDir` aktiviert, Version auf
+`0.19.2-threadnet.8`, Fork-Doku um den Auslieferungsweg und den Rebase-Hinweis ergänzt
+(diese eine Zeile ist der wahrscheinlichste stille Rückfall beim nächsten Rebase).
+
+**Verifiziert:**
+- URL-Auflösung im Widget: `…/widgets/element-call/assets/dfn3/v3/pkg/df_bg.wasm` ✓
+- CI-Pipeline #371 grün, `build_embedded` erfolgreich
+- **Das CI-Artefakt enthält die Assets** (24,3 MB) — nicht nur der lokale Build
+
+### Korrektur einer Zahl aus der Entscheidungsvorlage
+
+Ich hatte beim Abfragen der Asset-Entscheidung gesagt, das npm-Paket wachse „von ~2 MB auf
+~25 MB". **Gemessen: 41 → 66 MB.** Der Aufschlag stimmt (+24 MB), die Ausgangsbasis war
+falsch — das Paket enthielt bereits 17,6 MB Source-Maps und 16 MB Crypto-/Vision-wasm. Der
+relative Aufschlag ist also +60 %, nicht das Zwölffache.
+
+### Offen — beides bewusst nicht von mir ausgelöst
+
+1. **`publish_npm`** steht auf `manual`. Laut Fork-Doku §4 ist das Absicht: *„bewusst kein
+   Automatismus — Veröffentlichen bleibt ein Akt."* Auslösen gehört sorb.
+2. **Danach ThreadNet-Web:** Abhängigkeit auf `0.19.2-threadnet.8` anheben, bauen, Image in
+   die Registry, Tag im gitops-Repo anheben.
+3. **Abnahme im echten Call zu zweit** steht weiterhin aus.