AP-Pin fuer den Rundgang -- und drei Dinge, die dabei still falsch waren

TP25: das S22 laesst sich jetzt per access-list am Manager auf EINEN AP
festnageln (docs/tp25-pin-s22.sh, Umschalter in der Klick-Konsole). Damit
werden Einzel-AP-Abdeckungskarten messbar, statt dass der Client mitten im
Weg wechselt. Gepinnt wird der Standort, nicht das Band -- Band-Ping-Pong
(Fund C) bleibt damit ein echter Befund und wird nicht wegkonfiguriert.

Beim Bauen fielen drei Fehler auf, die alle dieselbe Form haben: eine
Konstante, die einmal richtig war.

1. Die AP-Zuordnung war VERTAUSCHT. server.py und tp25-gehweg-auswertung.py
   fuehren cap-wifi1/2 als ap1 -- live ist es ap2 (belegt ueber cap=,
   configuration= und Kanal). Baender stimmten, Identitaet nicht. Die
   cap-wifiN-Nummern vergibt der Manager dynamisch in der Anmeldereihenfolge
   der CAPs, jede feste Tabelle dazu wartet auf den naechsten AP-Reboot.
   server.py liest sie jetzt vom Geraet; die Auswertung ist NOCH NICHT
   angefasst -- offen ist, ob die Funde vom 08-21 mit vertauschten AP-Namen
   notiert sind.

2. Das Laufverzeichnis war beim Serverstart eingefroren. Die Konsole laeuft
   als Dauer-Preview, der Messlauf legt spaeter ein neues Verzeichnis an --
   Marker waeren in den Lauf von gestern gewandert, waehrend der Sampler ins
   neue schreibt. tp25-walk-messung.sh hinterlaesst jetzt einen Zeiger.

3. Das Startbanner nannte eine hartkodierte IP (10.40.10.183 = MacBook Air).
   Auf dem Mac mini ist es 10.40.10.82, und genau die falsche Adresse ging
   ans Telefon: "geht nicht" bei einem Server, der sauber auf 0.0.0.0 lauschte.
   Es werden jetzt die real gefundenen Interface-Adressen gedruckt.

Ausserdem, aus dem Test heraus:
- Ein vom Pin ABGEWIESENER Verbindungsversuch ist in den Ping-Daten nicht von
  einem Funkloch zu unterscheiden, und der Manager protokolliert ihn auf
  info-Ebene nicht. Android quittiert ihn mit "Verbindung fehlgeschlagen" und
  waehlt das Netz ab -- danach misst der Rest des Rundgangs Stille. Die Konsole
  schlaegt deshalb mit Vollbanner, Ton und Vibration Alarm, sobald das gepinnte
  Geraet nirgends haengt.
- Die Konsole laeuft diesmal auf dem S22 selbst, also auf genau dem Geraet, das
  der Pin gleich vom WLAN wirft. Die Anweisung zum Wiederverbinden erscheint
  deshalb clientseitig VOR dem Abbruch.
- ThreadingHTTPServer: der Pin braucht ~8 s ueber SSH und haette sonst die
  ganze Seite blockiert, Not-Aus inklusive.

Governance: /interface wifi access-list steht unter KEINER ComplianceRule --
der Change erzeugt keinen Drift und laesst sich nicht als Transaktion fuehren.
Fuer eine Messung vertretbar; relevant wird es, wenn Fund E (signal-range)
dauerhaft dort landet.

teilprojekte.md: die beiden Hinweise auf die offene Transaktion
TEST-ether3-trunk-ap1-sideboard nachgezogen -- sie ist seit 08-22
zurueckgerollt, crs326-core ist transaktionsfrei.

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

docs/teilprojekte.md

@@ -67,9 +67,10 @@ ab jetzt bei jeder Änderung mitgezogen, nicht nur die TP-Abschnitte.)*
 **Nächster Schritt (Stand 2026-08-21 abends): TP25 — Steering-Test in den Schlafräumen.**
 > 📋 **Einstieg: [`handoff-tp25-session-20260821.md`](handoff-tp25-session-20260821.md)** — dort steht
 > der verifizierte Ist-Stand, die Messfallen und der nächste Test.
-> ⚠️ **Auf `crs326-core` ist eine Config-Transaktion OFFEN** (`TEST-ether3-trunk-ap1-sideboard`,
-> Frist 2026-09-04): ap1 hängt testweise am Sideboard, `ether3` wurde dafür zum Trunk. Die Compliance
-> ist deshalb **absichtlich** nicht 92/92 — `python3 nautobot/gc-transaktion.py status`.
+> ✅ **`crs326-core` ist transaktionsfrei (2026-08-22).** `TEST-ether3-trunk-ap1-sideboard` und
+> `TEST-infra-ssid-matter-pairing` sind beide zurückgerollt und geschlossen; ap1 hängt wieder auf
+> `ether15`, `ether3` ist wieder untagged VLAN40. Ein gemeldeter Drift ist ab jetzt **echt**, nicht
+> beabsichtigt — `python3 nautobot/gc-transaktion.py status`.
 > 🆕 **TP29** (Anwesenheitserkennung fürs Energiesparen) ist als Idee angelegt, nicht auf dem Pfad.
 > 📌 **Die TP6-Prämisse ist am 2026-08-20/21 gemessen** (Runbook §5): formal Fall B (+28…+47 ms unter
 > Dauer-Upload), aber im Videocall **nicht wahrnehmbar** — kein einziger Problem-Klick über sechs
@@ -1364,8 +1365,8 @@ FT kaschierte das bisher als „Roaming" statt „schwache Abdeckung".
 > ⇒ **Fund E** (`signal-range`-Boden am Manager) bleibt unverändert die richtige Maßnahme und ist nach
 > dem Rückbau der **oberste offene Punkt** in TP25 — nicht erledigt, nicht gegenstandslos.
 > 📋 **Übergabe: [`handoff-tp25-session-20260821.md`](handoff-tp25-session-20260821.md).**
-> ⚠️ **Auf `crs326-core` ist eine Config-Transaktion OFFEN** (`TEST-ether3-trunk-ap1-sideboard`, Scope
-> `bridge-vlan`, Frist 2026-09-04) — die Compliance ist deshalb **absichtlich** nicht 92/92.
+> ✅ **Transaktion `TEST-ether3-trunk-ap1-sideboard` am 2026-08-22 zurückgerollt und geschlossen**
+> (Scope `bridge-vlan`) — `ether3` ist wieder untagged VLAN40, Compliance zurück auf 92/92.
 > **Und das passiert TROTZ aktivem 802.11k/v und FT** — live geprüft: `st-main` mit `rrm=yes`/`wnm=yes`,
 > `ft-over-ds=yes`. Die Merkregel `ref_ft_is_not_roaming` („11k/v fehlen") ist damit **historisch**.
 > **Reihenfolge der Maßnahmen** (Doku §6, respektiert die User-Randbedingung „kein neuer AP, solange