CAPsMAN: slaves-datapath fehlte, IOT+MEDIA lagen 14h

Seit dem CAPsMAN-Cutover (2026-08-17) war `/interface wifi cap
slaves-datapath` auf ap1 und ap2 leer. Das ist das einzige Feld, das die
vom Manager erzeugten Slave-VAPs lokal in die Bridge haengt: der Core
schickt `datapath.bridge=bridge` zwar mit, der CAP uebernimmt davon aber
nur die vlan-id. Ergebnis: -iot, -media, -untrusted und -guest hingen in
gar keiner Bridge — Clients assoziierten sauber und bekamen nie DHCP.
`dirtyvader-main` lief weiter, weil wifi1/wifi2 statische Bridge-Ports
sind; genau das hat den Ausfall getarnt.

Fix live auf beiden APs: dp-caps-slaves (bridge=bridge, bewusst ohne
vlan-id) + slaves-datapath darauf. Die VAPs stehen seither als dynamische
Bridge-Ports mit pvid 30/40/50/90 in der Bridge.

Nicht die TP5-Haertung: torch auf vlan30 am Core leer UND kein einziger
DHCP-Eintrag im Drop-Log — es wurde nichts verworfen, es kam nichts an.

tp28-ap-wifi-reste-abraeumen.rsc hat den Ausfall nicht ausgeloest, aber
zementiert: mit den geloeschten datapath-Objekten gab es lokal nichts
mehr, worauf slaves-datapath haette zeigen koennen.

Die TP28-Abnahme "ohne jeden Aussetzer" ist korrigiert — sie zaehlte
Registrations, also genau die Metrik, die hier luegt. Abnahmekriterium
fuer WLAN-Umbauten ist ab jetzt eine frische DHCP-Lease pro SSID.

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

docs/teilprojekte.md

@@ -1358,7 +1358,33 @@ FT kaschierte das bisher als „Roaming" statt „schwache Abdeckung".
   liefert das Entscheidungskriterium). ⚠️ **Berührt TP5:** der Mesh-Verkehr braucht bei deny-by-default eine
   explizite `forward`-Zeile — s. TP5 Etappe 2.
 
-### TP28 — WLAN über CAPsMAN auf `crs326-core` ▸ ✅ **KOMPLETT (2026-08-18): Cutover + GC-Modell nachgezogen**
+### TP28 — WLAN über CAPsMAN auf `crs326-core` ▸ ✅ **KOMPLETT (2026-08-18)** — mit Nachtrag: **`slaves-datapath` fehlte, IOT+MEDIA lagen ~14 h**
+
+- 🔴🔴 **POST-MORTEM 2026-08-18 (gemeldet von Christoph: „die -iot-geräte sind offline … connect möglich, aber kein dhcp"):**
+  Seit dem Cutover hingen **alle Slave-VAPs in gar keiner Bridge**. `/interface wifi cap slaves-datapath`
+  war auf beiden APs leer — und genau dieses Feld ist das Einzige, was die vom Manager erzeugten
+  Slave-VAPs lokal in die Bridge haengt. Der Manager schickt `datapath.bridge=bridge` zwar mit,
+  **der CAP uebernimmt davon nur die `vlan-id`.** Betroffen: `dirtyvader-iot`, `-media`, `-untrusted`,
+  `-guest`. Nicht betroffen: `dirtyvader-main` — dessen Master-Radios `wifi1`/`wifi2` sind
+  **statische** Bridge-Ports und liefen deshalb weiter. Genau das machte den Ausfall unsichtbar.
+  - **Fix (live 2026-08-18 auf ap1 + ap2, seither Soll im Template):**
+    `/interface wifi datapath add name=dp-caps-slaves bridge=bridge` +
+    `/interface wifi cap set slaves-datapath=dp-caps-slaves`. Das Objekt traegt **bewusst keine
+    `vlan-id`** — die liefert der Manager pro VAP. Danach erscheinen die VAPs als **dynamische
+    Bridge-Ports mit `pvid`=30/40/50/90**, und DHCP laeuft sofort wieder.
+  - 🔴 **Die Diagnose-Lehre: „Client assoziiert" beweist gar nichts.** Am Manager standen 25 IOT-
+    Registrations — das WLAN sah perfekt aus. Erst zwei Reads trennten die Faelle:
+    `torch` auf `vlan30` am Core (**leer**) und der TP5-Drop-Log (**kein einziger DHCP-Eintrag**).
+    Beides leer heisst: es wird nichts verworfen, es **kommt** nichts. Damit war die Firewall
+    — der naheliegende Verdaechtige nach der Haertung derselben Nacht — in zwei Minuten entlastet.
+  - ⚠️ **Die Abnahme „✅ Ohne jeden Aussetzer" weiter unten war falsch.** Sie zaehlte Registrations
+    (30 Clients, beide CAPs `Ok`, 7 VAPs je AP) — also genau die Metrik, die hier luegt. Keiner
+    dieser Werte beruehrt die Bridge. Ein Abnahmekriterium fuer WLAN-Umbauten ist ab jetzt eine
+    **frische DHCP-Lease pro SSID**, nicht die Registration-Table.
+  - **`routeros/tp28-ap-wifi-reste-abraeumen.rsc` hat den Ausfall nicht ausgeloest, aber zementiert:**
+    mit den geloeschten datapath-Objekten gab es lokal nichts mehr, worauf `slaves-datapath` haette
+    zeigen koennen. Der Ein-Zeilen-Fix war damit weg. Nachtrag steht im Skript.
+
 - ✅ **Der offene GC-Rest ist erledigt (2026-08-18).** Die fuenf `wifi-*`-ComplianceFeatures haengen
   jetzt am **Core**, der AP-Zweig des Templates ist auf eine einzige Zeile eingedampft
   (`/interface wifi cap set discovery-interfaces=vlanXX enabled=yes`).