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>

routeros/tp28-ap-wifi-reste-abraeumen.rsc

@@ -32,3 +32,32 @@
 :do { /interface wifi channel remove [find] } on-error={ :log info "tp28c: channel warf" }
 
 :log info ("tp28c: ENDE cfg=" . [:tostr [:len [/interface wifi configuration find]]] . " sec=" . [:tostr [:len [/interface wifi security find]]] . " dp=" . [:tostr [:len [/interface wifi datapath find]]] . " ch=" . [:tostr [:len [/interface wifi channel find]]] . " st=" . [:tostr [:len [/interface wifi steering find]]] . " cap-enabled=" . [:tostr [/interface wifi cap get enabled]])
+
+# ---------------------------------------------------------------------------
+# 🔴 NACHTRAG 2026-08-18, nach rund 14 h Ausfall von IOT + MEDIA:
+# Die Annahme oben ("Client-Verbindungen bleiben unberuehrt") stimmte — das
+# Skript hat den Ausfall NICHT ausgeloest. Die Bruchstelle liegt frueher, im
+# CAPsMAN-Cutover selbst (2026-08-17): dabei wurde `/interface wifi cap
+# slaves-datapath` nie gesetzt. 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 aber nur die
+# vlan-id. Seit dem Cutover assoziierten IOT-/MEDIA-Clients also sauber, ihre
+# Frames gingen nirgendwo hin — am Core kam auf vlan30/vlan40 kein einziges
+# Paket an. Die Master-Radios (wifi1/wifi2 = dirtyvader-main) sind statische
+# Bridge-Ports und liefen weiter, deshalb sah das WLAN von aussen "halb ok" aus.
+# Belege: `slaves-datapath` kommt in keiner Provisionierungs-Referenz vor
+# (routeros/.secrets/ap*-prov-base.rsc), und die letzten IOT-/MEDIA-Leases
+# stammen vom Abend des 2026-08-17.
+#
+# Dieses Skript hat den Schaden aber ZEMENTIERT: mit den geloeschten datapath-
+# Objekten gab es lokal nichts mehr, worauf `slaves-datapath` haette zeigen
+# koennen. Der naheliegende Ein-Zeilen-Fix war damit nicht mehr moeglich.
+#
+# Reparatur (ap1 und ap2, live 2026-08-18, seither im Template als Soll):
+#   /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 kommt pro VAP vom Manager.
+#
+# LEHRE: `remove [find]` ohne Ruecksicht auf Referenzen aus /interface wifi cap.
+# Vor dem Abraeumen pruefen: :put [/interface wifi cap get slaves-datapath]
+# ---------------------------------------------------------------------------