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>

nautobot/mikrotik_routeros.j2

@@ -326,7 +326,7 @@
 # Referenz: routeros/state-backups/ap1-gc-backup-scrubbed-20260813.cfg
 # =====================================================================================
 
-# [1] WLAN — ein CAP haelt KEINE eigene WLAN-Config.
+# [1] WLAN — ein CAP haelt keine eigenen SSIDs, aber sehr wohl den lokalen Anschluss.
 #     Bis 2026-08-18 rendert dieser Zweig Kanaele, Datapaths, Security, Configurations
 #     und Steering. Das war der Standalone-Stand von TP3; seit dem CAPsMAN-Cutover
 #     (TP28, 2026-08-17) kommen all diese Objekte vom Manager `crs326-core` und werden
@@ -336,11 +336,29 @@
 #     den defconf-Firewallregeln in TP26). Sie sind am 2026-08-18 abgeraeumt worden.
 #
 #     Die fuenf wifi-*-ComplianceFeatures greifen jetzt am Core, s. dort [6b].
-#     Hier bleibt genau eine Zeile: der CAP muss wissen, wo er suchen soll.
+#     Hier bleiben zwei Zeilen: wo der CAP seinen Manager suchen soll, und WOHIN er
+#     die vom Manager erzeugten Slave-VAPs haengt.
 #     ⚠️ `discovery-interfaces` ist Layer-2-Discovery — der Manager wird ueber seine
 #     MAC gefunden, nicht ueber eine IP. Deshalb muessen MNDP (udp/5678) und CAPWAP
 #     (udp/5246-5247) in der input-Kette des Core offen bleiben (TP5 Etappe 4).
-/interface wifi cap set discovery-interfaces=vlan{{ ap.mgmt.vlan }} enabled=yes
+#
+# 🔴 `slaves-datapath` IST NICHT OPTIONAL — Ausfall 2026-08-18, rund 14 h IOT+MEDIA:
+#     Der Manager schickt `datapath.bridge=bridge` zwar mit, der CAP uebernimmt davon
+#     aber NUR die vlan-id — die Bridge-Mitgliedschaft ist und bleibt lokal. Die
+#     Master-Radios wifi1/wifi2 sind statische Bridge-Ports (s. [4b]) und liefen
+#     deshalb weiter; die dynamischen Slave-VAPs (iot/media/untrusted/guest) haengen
+#     dagegen in GAR KEINER Bridge, solange `slaves-datapath` auf kein lokales
+#     datapath-Objekt zeigt. Beim Cutover (2026-08-17) wurde das Feld nie gesetzt —
+#     der Ausfall beginnt dort, nicht bei der TP5-Haertung und nicht beim Abraeumen
+#     der Standalone-Reste am 2026-08-18 (das hat ihn nur unreparierbar gemacht).
+#     Symptom: Client assoziiert sauber (am Manager als Registration sichtbar!),
+#     bekommt aber nie DHCP; am Core kommt auf dem VLAN kein einziges Frame an —
+#     `torch` leer UND Drop-Log leer, es wird also nichts verworfen, es kommt nichts.
+#     Das Objekt traegt bewusst KEINE vlan-id: die liefert der Manager pro VAP.
+/interface wifi cap set discovery-interfaces=vlan{{ ap.mgmt.vlan }} enabled=yes slaves-datapath=dp-caps-slaves
+# ⚠️ Export-Reihenfolge != Deploy-Reihenfolge: RouterOS exportiert `cap` VOR `datapath`,
+#    beim Push muss das datapath-Objekt aber ZUERST existieren.
+/interface wifi datapath add bridge={{ ap.bridge }} comment="TP28-fix: bridge fuer CAPsMAN-Slave-VAPs" name=dp-caps-slaves
 
 # [4b] BRIDGE-PORTS — ether2 fehlt bewusst: seit der Uplink-Umstellung auf ether1 (PoE)
 #      ist er KEIN Bridge-Port mehr. ether1 traegt kein comment=defconf (beim Rebuild
@@ -353,8 +371,11 @@
 {% endfor %}
 /interface bridge port add bridge={{ ap.bridge }} interface={{ uplink }}
 
-# [5] BRIDGE-VLAN — Nur Master-Radios sind Bridge-Ports (Slave-VAPs forwarden darueber),
-#     deshalb muessen wifi1/wifi2 tagged-Member je Client-VLAN sein. Die frueheren
+# [5] BRIDGE-VLAN — wifi1/wifi2 sind tagged-Member je Client-VLAN. Die Begruendung von
+#     2026-08-17 ("Slave-VAPs forwarden ueber den Master") war falsch: mit gesetztem
+#     `slaves-datapath` haengt jeder Slave-VAP als eigener DYNAMISCHER Bridge-Port mit
+#     pvid = seiner Manager-vlan-id in der Bridge. Die tagged-Zeilen bleiben trotzdem
+#     stehen — sie kosten nichts und tragen den Uplink-Trunk. Die frueheren
 #     "Ausnahmen" fallen hier aus den Daten heraus: IOT hat bands=["2g"] -> nur wifi2.
 /interface bridge vlan add bridge={{ ap.bridge }} untagged={{ ap.bridge }},{{ uplink }} vlan-ids={{ ap.native_vlan }}
 {% for z in ap.zones %}