ComplianceRule wifi-access-list: die letzte ungepruefte Sektion schliessen

/interface wifi access-list stand unter KEINER ComplianceRule. Eintraege dort
erzeugten keinen Drift und liessen sich nicht als Config-Transaktion fuehren --
gc-transaktion.py verlangt eine ComplianceRule als --scope. Seit dem 22.8. ist
das nicht mehr theoretisch: docs/tp25-pin-s22.sh schreibt bei jedem Messrundgang
Regeln dorthin, und TP25 Fund E (signal-range-Boden) wuerde dauerhaft genau in
diesem blinden Fleck landen.

  - nautobot/ingest-wifi-access-list-rule.py (idempotent, Dry-Run default)
  - Template-Abschnitt [6c], bewusst NUR Kommentare: der Soll-Zustand ist LEER,
    und das ist die Aussage. Die intended config gewinnt keine wirksame Zeile.
    Nach bf-golden-config gepusht (51c11f0), Repo-Sync SUCCESS.

ZWEI KORREKTUREN AN DER AUFGABENSTELLUNG:

1. Der Zaehler geht auf 96, nicht auf 94. Die Regeln gelten PLATTFORMWEIT, nicht
   geraetespezifisch -- 92 Checks waren exakt 23 Rules x 4 Geraete, jetzt sind es
   24 x 4. Die Annahme "2 geraete-relevante Checks" war falsch.
2. Vor Beginn stand bereits ein Drift in der Anzeige (bridge-vlan auf
   crs326-core, ether3 als Trunk), obwohl der Sideboard-Rollback am 08-22
   gelandet war. Das Geraet war live korrekt -- die Compliance vergleicht gegen
   das letzte BACKUP, und das war aelter als der Rollback. Mit dem Refresh weg.

WIRKSAMKEIT BEWIESEN, nicht behauptet (TP22-Regel "Job-Status ist kein
Wirksamkeitsnachweis"):
  96/96 compliant, 0 Drifts
  -> Test-Eintrag mit nicht existierender MAC (kein echter Client betroffen)
  -> 95/96, extra = exakt diese Zeile bei crs326-core | wifi-access-list
  -> Eintrag entfernt -> 96/96, 0 Drifts
  Zusaetzlich: gc-transaktion.py akzeptiert --scope wifi-access-list.
  Ausserdem geprueft: 4 Compliance-Datensaetze (einer je Geraet), und der
  [6c]-Block steht wirklich in der intended config von crs326-core.

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

docs/teilprojekte.md

@@ -52,7 +52,8 @@ ab jetzt bei jeder Änderung mitgezogen, nicht nur die TP-Abschnitte.)*
   08-18) — TP19 ist geschlossen; `cudy1` hängt stromlos an core `ether11`, physischer Ausbau ist hands-on.
 - **Kontrolle / Governance:** MikroMCP für Reads/Debug (alle 4 Geräte in der Registry),
   **Config-Änderungen ausschließlich über Nautobot Golden Config** (TP21/TP22 — Deploy-Pipeline scharf,
-  **92/92 Compliance-Checks grün, 0 Drifts** bei **23 Rules**, Stand 2026-08-18).
+  **96/96 Compliance-Checks grün, 0 Drifts** bei **24 Rules × 4 Geräten**, Stand 2026-08-23 —
+  neu dazu: **`wifi-access-list`**, s. TP22-Nachtrag).
 
 <details><summary>📜 Historische Fassung (Stand bis 2026-08-08, Topologie <b>vor</b> dem Core-Cutover — bewusst erhalten, nicht als Ist lesen)</summary>
 
@@ -1214,6 +1215,26 @@ FT kaschierte das bisher als „Roaming" statt „schwache Abdeckung".
 - **Nutzen:** Drift-Erkennung + reproduzierbarer Rebuild jedes Geräts aus dem Modell.
 - **Abh.:** TP21 ✅ (Plattform/Modell/Templates), TP20 ✅, einheitliches Admin-PW ✅. **Danach ist der kritische Pfad frei für TP5 (Deny-by-default) → TP6 (CAKE).**
 
+- ✅ **Nachtrag 2026-08-23 — Governance-Lücke geschlossen: ComplianceRule `wifi-access-list`.**
+  `/interface wifi access-list` stand unter **keiner** Regel: Einträge dort erzeugten keinen Drift
+  und ließen sich nicht als Transaktion führen (`gc-transaktion.py` verlangt eine ComplianceRule
+  als `--scope`). Seit `docs/tp25-pin-s22.sh` schreibt jeder Messrundgang dort Regeln, und **TP25
+  Fund E** (`signal-range`-Boden) würde dauerhaft genau dort landen.
+  Angelegt per `nautobot/ingest-wifi-access-list-rule.py` (idempotent), Template um den
+  dokumentierten Abschnitt **[6c]** ergänzt (**nur Kommentare** — der Soll-Zustand ist *leer*,
+  und das ist die Aussage).
+  - 🔢 **Zählerkorrektur: 92 → 96, nicht 94.** Die Regeln gelten **plattformweit**, nicht
+    gerätespezifisch: 24 Rules × 4 Geräte. Die Annahme „nur 2 Geräte betroffen" war falsch.
+  - ✅ **Wirksamkeit bewiesen, nicht behauptet** (die TP22-Regel „Job-Status ist kein
+    Wirksamkeitsnachweis"): Test-Eintrag mit einer nicht existierenden MAC gesetzt →
+    **95/96 mit exakt dieser Zeile als `extra`** → Eintrag entfernt → **96/96, 0 Drifts**.
+    Zusätzlich geprüft: `gc-transaktion.py` akzeptiert `--scope wifi-access-list` jetzt.
+  - 🔎 **Nebenbefund beim Start:** ein `bridge-vlan`-Drift auf `crs326-core` stand noch in der
+    Anzeige (ether3 als Trunk), obwohl der Sideboard-Rollback am 08-22 gelandet war. Das Gerät
+    war live korrekt; die **Compliance vergleicht gegen das letzte Backup**, und das war älter
+    als der Rollback. Mit dem Refresh verschwunden. Merkregel bleibt: bei einem Drift zuerst
+    fragen, wie alt das Backup ist.
+
 ### TP23 — DNS-Policy & Self-Service-Ausnahmen ▸ ⏳ **STUFE 1 DURCH, STUFE 2 VORBEREITET (2026-08-18)**
 - ✅ **Stufe 1 — DoH auf dem Core scharf** (`routeros/tp23-stufe1-doh-core.rsc`), schliesst zugleich
   **TP21.1 TODO 1**. `use-doh-server=https://px35ynlol3.cloudflare-gateway.com/dns-query`,