TP25: Drift-Luecke geschlossen (72/72) — und zwei fehlende Compliance-Sektionen aufgedeckt

Die neuen Funkparameter stehen jetzt in der SoT, nicht nur auf dem Geraet:
radios[5g].width 20/40/80mhz -> 20/40mhz, DEVICE_CHANNELS[ap2][5g] 149 -> 44.
Config-Context gepatcht, dann Backup -> Intended -> Compliance: 72/72, keine
Drifts. Ein kuenftiger Deploy kann die Fixes damit nicht zurueckdrehen.

Bemerkenswert: width fuer 2,4 GHz stand im Config-Context die ganze Zeit
korrekt auf 20mhz. Die SoT war richtig, das Geraet hat sie nicht befolgt —
der Beweis, dass das Problem der Inline-Override war und nicht die Datenlage.

Beim Nachpruefen, ob "72/72" die Funkparameter ueberhaupt abdeckt, sind zwei
Luecken aufgefallen (18 Compliance-Rules abgefragt):

- /interface wifi (Interface-Sektion) hat KEINE Rule. Die fuenf wifi-*-Features
  decken nur die Profilobjekte ab. Die Inline-Overrides leben in der
  Interface-Sektion — deshalb blieben Fund A und D seit 2026-08-08 unentdeckt,
  waehrend die Flotte durchgehend "compliant" meldete.

- /ip firewall filter hat KEINE Rule, es gibt nur ip-firewall-nat. Die
  TP5-Zeile "laeuft ueber ip-firewall-*-Features aus TP22" war damit
  irreführend. Die 11 Etappe-2-Regeln und der kommende Deny-by-default sind
  nicht drift-ueberwacht; "72/72" sagt ueber die Firewall nichts aus.
  -> als Vorbedingung fuer TP5 Etappe 3 eingetragen.

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

docs/teilprojekte.md

@@ -1098,8 +1098,29 @@ FT kaschierte das bisher als „Roaming" statt „schwache Abdeckung".
    einzige verbleibende Griff gegen klebende Clients.)*
 5. **Re-Walk + Dead-Spot-Kartierung** (der übernommene TP3.3-Rest) — **erst jetzt**, gegen die korrigierte Basis.
    Vorher gemessene Werte sind wertlos.
-6. **Compliance-Feature** auf `/interface/wifi channel` + `/interface/wifi` erweitern, damit A und D nicht
-   wiederkommen.
+6. ⏳ **Drift-Lücke — Teil 1 GESCHLOSSEN, Teil 2 offen und jetzt exakt vermessen (2026-08-17).**
+   - ✅ **Der akute Teil ist zu:** die neuen Werte stehen in der SoT (`nautobot/ingest-ap-configcontext.py`:
+     `radios[5g].width` `20/40/80mhz`→`20/40mhz`, `DEVICE_CHANNELS[ap2][5g]` `149`→`44`), Config-Context
+     gepatcht, dann **Backup → Intended → Compliance** → **72/72, keine Drifts.** Damit kann ein künftiger
+     Deploy die Fixes **nicht** mehr zurückdrehen. *(Bemerkenswert: `width` für 2,4 GHz stand dort die ganze
+     Zeit korrekt auf `20mhz` — die SoT war richtig, nur das Gerät hat sie nicht befolgt. Der Beweis, dass
+     das Problem der Inline-Override war und nicht die Datenlage.)*
+   - 🔴 **Der Erkennungsteil bleibt offen. Die 18 Compliance-Rules abgefragt — es fehlen genau zwei Sektionen:**
+     | vorhanden | fehlt |
+     |---|---|
+     | `/interface wifi channel` · `… configuration` · `… datapath` · `… security` · `… steering` | **`/interface wifi`** (die Interface-Sektion) |
+     | `/ip firewall nat` | **`/ip firewall filter`** |
+   - **Folge 1 (WLAN):** die fünf `wifi-*`-Features decken nur die **Profil**objekte ab. Die Inline-Overrides
+     leben in `/interface wifi` — **deshalb sind Fund A und D seit dem 2026-08-08 unentdeckt geblieben, obwohl
+     die Flotte durchgehend „compliant" meldete.** Genau die Lücke, die ich unter Beobachtung 5 vermutet hatte;
+     sie ist jetzt belegt, nicht vermutet. Erschwerend: die VAP-MAC-Adressen sind gerätespezifisch (Template
+     Zeile ~220 nimmt sie bewusst raus), eine Rule auf diese Sektion braucht also erst
+     `local_config_context_data` je AP.
+   - 🔴 **Folge 2 (und die ist gewichtiger): `/ip firewall filter` ist NICHT abgedeckt.** Die TP5-Zeile
+     „läuft über Nautobot GC (`ip-firewall-*`-Features aus TP22)" ist damit **irreführend — es existiert nur
+     NAT.** Die 11 Etappe-2-Regeln und der kommende Deny-by-default sind **nicht drift-überwacht**:
+     „72/72 compliant" sagt über die Firewall **gar nichts**. ➡️ **Das gehört VOR TP5 Etappe 3**, denn eine
+     Drop-Regel, die niemand überwacht, ist genau die, die still verschwindet.
 - ⚠️ **`steering=`/Channel-Änderungen re-applien alle VAPs und werfen jeden Client kurz raus** (TP3.3 am
   2026-08-13 gemessen: ap1 25→2, ap2 7→14). **Nicht während eines Calls deployen.** `/system backup` je AP vorher.
 - **Abh.:** TP22 ✅ (GC-Deploy-Pipeline). Übernimmt den offenen Rest von **TP3.3**, verwandt **TP3.2** (Coverage-Doku
@@ -1179,9 +1200,12 @@ TP5 E1 ✅ ──► TP5 E2 ✅ ──► [mehrtägiges stilles Fenster] ──
 2. ✅ **TP5 Etappe 2 — 11 Whitelist-Regeln** (2026-08-17, ConfigPlan `86fbd528`). Log-Regel verstummt.
 3. ⏳ **Wartezeit, kein Arbeitsschritt:** das Log muss **mehrere Tage** still bleiben. 70 Sekunden Stille sind
    keine Aussage — es gibt Geräte, die einmal pro Woche funken. **Das ist das Gate, nicht eine Meinung.**
-4. 🔜 **TP5 Etappe 3 — Drop scharf schalten.** Vorbedingungen: das stille Fenster **und** D2 (iPhone `.30.201`
-   ins MAIN-SSID, Hands-on Christoph). 🛟 Auto-Revert-Scheduler davor (auf dem Core möglich, `device-mode`
-   erlaubt scheduler — auf den hAPs nicht).
+4. 🔜 **TP5 Etappe 3 — Drop scharf schalten.** Vorbedingungen: das stille Fenster · D2 (iPhone `.30.201`
+   ins MAIN-SSID, Hands-on Christoph) · **und neu: eine Compliance-Rule auf `/ip firewall filter`.**
+   🔴 **Am 2026-08-17 festgestellt: die Filter-Kette ist NICHT drift-überwacht** — es gibt nur
+   `ip-firewall-nat`. Eine Deny-by-default-Regel ohne Drift-Erkennung ist genau die, die still verschwindet
+   und niemandem auffällt, bis etwas nicht mehr geht. **Siehe TP25 Schritt 6.**
+   🛟 Auto-Revert-Scheduler davor (auf dem Core möglich, `device-mode` erlaubt scheduler — auf den hAPs nicht).
 5. 🔜 **TP5 Etappe 4 — UNTRUSTED/GUEST Internet-only + MGMT isolieren** (`seal-lan` verengen → schaltet
    zugleich die 5 toten mDNS-`input`-Regeln scharf). **Mit im Paket:** TP7.1 (SSDP-Reflector für die
    macOS-Sonos-App) — gemeinsam testen, sonst prüft man zweimal dieselbe Strecke.