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/README.md

@@ -24,3 +24,20 @@ python3 nautobot/ingest-baseline.py --apply  # schreiben
   einen `Controller` (bei uns logisch, `controller_device` leer — kein CAPsMAN).
 - `RadioProfile.channel_width` will Integer (`[20,40,80]`), nicht `"20mhz"`.
 - IP↔Interface läuft über `/ipam/ip-address-to-interface/`.
+
+## `ingest-wifi-access-list-rule.py`
+Legt ComplianceFeature + ComplianceRule **`wifi-access-list`** an (Plattform RouterOS,
+`match_config=/interface wifi access-list`). Idempotent, Dry-Run ist Standard.
+
+```bash
+export NAUTOBOT_TOKEN=...
+python3 nautobot/ingest-wifi-access-list-rule.py --apply
+```
+
+**Warum es die Rule braucht:** ohne sie erzeugen Eintraege in der access-list **keinen Drift**
+und lassen sich nicht als Config-Transaktion fuehren -- `gc-transaktion.py` verlangt eine
+ComplianceRule als `--scope`. `docs/tp25-pin-s22.sh` schreibt dort bei jedem Messrundgang, und
+TP25 Fund E (`signal-range`-Boden) landet dauerhaft dort.
+
+**Der Soll-Zustand ist leer** und steht als Kommentarblock `[6c]` im Template. Waehrend eines
+Messlaufs ist der Drift **erwartet** und gehoert als offene Transaktion gefuehrt.