Uebergabe korrigiert: der AP-Cleanup war falsch abgenommen

Ich hatte "30 Clients vorher, 30 nachher, kein Aussetzer" attestiert. Genau
diese Zahl hat einen laufenden Ausfall verdeckt: seit dem CAPsMAN-Cutover vom
17. war slaves-datapath auf beiden APs leer, IOT/MEDIA/UNTRUSTED/GUEST hingen
in keiner Bridge, Clients assoziierten und bekamen nie DHCP -- 14 Stunden.
Die Registration-Table zeigte derweil zufriedene Clients.

Abnahme fuer WLAN-Umbauten ist eine frische DHCP-Lease pro SSID, nicht die
Registration-Table. In der Uebergabe nachgetragen.

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

docs/handoff-doku-session-20260818.md

@@ -83,9 +83,34 @@ Chronologisch, alles verifiziert und committet:
    Quelle, DHCP-Option 42, ComplianceRule `system-ntp`.
 6. **TP7.1 — SSDP-Relay** als LXC 108 auf pve. User-bestätigt: „sonos ist da!"
 7. **TP28-Rest — GC-Modell auf CAPsMAN umgebaut.** Die APs trugen noch die komplette
-   Standalone-WLAN-Config aus TP3; abgeräumt ohne einen Client zu verlieren.
+   Standalone-WLAN-Config aus TP3; abgeräumt.
 8. **TP19 und TP3.2 geschlossen.**
 
+### ⚠️ Korrektur zu Punkt 7 — und die wichtigste Lehre der ganzen Nacht
+
+Ich hatte den AP-Cleanup mit „30 Clients vorher, 30 nachher, kein Aussetzer" abgenommen. **Das war der
+falsche Maßstab.** Parallel lief bereits ein Ausfall, den genau diese Zahl verdeckt hat:
+
+Seit dem CAPsMAN-Cutover vom **08-17** war `/interface wifi cap slaves-datapath` auf beiden APs **leer**
+— das einzige Feld, das die vom Manager erzeugten Slave-VAPs lokal in die Bridge hängt. Der Core schickt
+`datapath.bridge=bridge` mit, der CAP übernimmt davon aber **nur die `vlan-id`**. Folge: `-iot`, `-media`,
+`-untrusted` und `-guest` hingen **in gar keiner Bridge**. Clients assoziierten sauber und bekamen
+**nie DHCP** — **14 Stunden lang**. `dirtyvader-main` lief weiter, weil `wifi1`/`wifi2` statische
+Bridge-Ports sind, und hat den Ausfall getarnt.
+
+Gefunden und behoben hat es Christoph am 08-18 um 09:13 (Commit `1ba8260`): `dp-caps-slaves`
+(`bridge=bridge`, bewusst **ohne** `vlan-id`) + `slaves-datapath` darauf, auf beiden APs.
+
+**Zwei Konsequenzen, die du kennen solltest:**
+
+1. **Die Registration-Table ist kein Abnahmekriterium.** Sie zeigte während des Ausfalls zufriedene
+   IOT-Clients — und ich habe damit „kein Aussetzer" attestiert. **Richtig ist eine frische DHCP-Lease
+   pro SSID.** Steht inzwischen so in `CLAUDE.md`.
+2. **Es war nicht die TP5-Härtung**, obwohl der zeitliche Zusammenfall das nahelegt: `torch` auf vlan30
+   am Core war leer **und** der TP5-Drop-Log zeigte nichts. Beides leer heißt: es kommt nichts an, es
+   wird nichts verworfen → **L2-Problem, nicht Firewall**. Diese Merkregel steht jetzt ebenfalls in
+   `CLAUDE.md` und ist bei künftigen „connect ok, kein DHCP"-Fällen der erste Griff.
+
 **Nautobot-Betrieb:** der Stack hat sich zweimal selbst umgebracht. Ursache war der **Image-Healthcheck**
 (voller Django-Start alle 10 s, Aufrufe stapeln sich → ENOMEM → DSM räumt ab), nicht Celery. Behoben.
 Steht in TP21.