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>

nautobot/mikrotik_routeros.j2

@@ -212,6 +212,28 @@
 /interface wifi provisioning add action=create-dynamic-enabled comment="ap2 5GHz" master-configuration=cfg-main-5g-ap2 radio-mac=D0:EA:11:4D:40:3E slave-configurations=cfg-media,cfg-untrusted,cfg-guest
 /interface wifi provisioning add action=create-dynamic-enabled comment="ap2 2.4GHz" master-configuration=cfg-main-2g-ap2 radio-mac=D0:EA:11:4D:40:3F slave-configurations=cfg-iot,cfg-media,cfg-untrusted,cfg-guest
 
+# [6c] WLAN ACCESS-LIST — der Soll-Zustand ist LEER, und das ist eine Aussage.
+#
+#      Bis 2026-08-22 stand dieser Abschnitt unter KEINER ComplianceRule. Aenderungen
+#      dort erzeugten keinen Drift und liessen sich nicht als Transaktion fuehren --
+#      `gc-transaktion.py` verlangt eine ComplianceRule als --scope. Das war nicht
+#      theoretisch: `docs/tp25-pin-s22.sh` schreibt bei jedem Messrundgang
+#      access-list-Regeln (Kommentar TP25-PIN-S22) auf den Manager, um ein Telefon auf
+#      einen AP festzunageln.
+#
+#      Seit der ComplianceRule `wifi-access-list` faellt jeder Eintrag hier auf.
+#      Waehrend eines Messlaufs ist der gemeldete Drift ERWARTET -- dann gehoert er als
+#      offene Transaktion gefuehrt:
+#        python3 nautobot/gc-transaktion.py begin --device crs326-core \
+#            --scope wifi-access-list --change-id TEST-... --expires JJJJ-MM-TT
+#
+#      🔴 Hier landet TP25 **Fund E** (`signal-range`-Boden gegen klebende Clients),
+#      sobald er entschieden ist. Stand 2026-08-22 ist er es NICHT: der Sticky-Client
+#      vom 08-20 reproduzierte sich beim Rundgang am 08-22 nicht, und in den schwachen
+#      Raeumen gibt es keinen besseren AP, auf den ein Boden steuern koennte. Ein
+#      voreilig gesetzter Boden verschlechtert die Terrasse, statt zu helfen.
+#      Vor dem Eintragen also: Sticky-Fall erneut messen. Siehe teilprojekte.md TP25.
+
 # Kanonischer Mgmt-Nummernplan (User-Bestaetigung 2026-08-13, verbindlich):
 #   core .99.1 | branch .99.2 | ap1 .99.11 | ap2 .99.12
 /ip dns static add address=10.40.99.1 comment="core = GW/Router" name=router.lan type=A