TIMMERFLOTTE angelernt, -infra wieder deaktiviert

Der Workaround aus TP12.1 ist durchgespielt: dirtyvader-infra temporaer auf
ap2, iPhone auf VLAN20, TIMMERFLOTTE per Companion-App angelernt (25,44 C /
53,1 % rF / Batterie 100 %, Technik UG). SSID danach wieder vom Funk;
cfg-infra/dp-infra/sec-infra bleiben auf User-Wunsch inaktiv am Manager
stehen, damit das naechste Thread-Geraet ein Zweizeiler ist. Beide Akten
geschlossen, crs326-core transaktionsfrei.

TP12.1 bleibt offen: der Workaround umgeht das fehlende IPv6-Routing, er
behebt es nicht.

Neuer Gotcha in CLAUDE.md, an dem ich mich heute selbst verrannt habe:
slave-configurations zu setzen bewirkt am Funk nichts ohne
remote-cap provision -- und zwar in BEIDE Richtungen, auch beim Entfernen.
Schlimmer: beim Rueckbau wird der Interface-Kommentar geleert, waehrend der
VAP weitersendet. Ich habe auf comment~"dirtyvader-infra" geprueft, nichts
gefunden und "weg" gemeldet -- tatsaechlich liefen wifi13/wifi18 mit vlan=20
weiter. Richtige Abnahme ist datapath.vlan-id am CAP. Also wieder: Wirkung
messen, nicht Anzeige.

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

docs/transaktionen/TEST-infra-ssid-matter-pairing.json

@@ -8,7 +8,8 @@
   "reason": "dirtyvader-infra temporaer auf ap2: iPhone fuer Matter-Commissioning auf VLAN20 (TP12.1)",
   "started": "2026-08-22",
   "expires": "2026-08-29",
-  "state": "open",
+  "state": "rolledback",
   "snapshot": "docs/transaktionen/TEST-infra-ssid-matter-pairing.snapshot.rsc",
-  "device_backup": ""
+  "device_backup": "",
+  "closed": "2026-08-22"
 }

docs/transaktionen/TEST-infra-ssid-matter-pairing.rollback-deployed.rsc

@@ -0,0 +1,6 @@
+# TATSAECHLICH DEPLOYT am 2026-08-22 (Plan 1469f0f7-fc52-47e1-bd65-a83ac709d89c, Completed).
+# Danach ZWINGEND: /interface wifi capsman remote-cap provision [find where identity="ap2"]
+# Ohne die Re-Provisionierung bleiben die VAPs am CAP bestehen und senden weiter.
+# Rueckbau: dirtyvader-infra wieder von ap2 nehmen. Stand vor dem Change (live gelesen 2026-08-22).
+/interface wifi provisioning set [find where comment="ap2 5GHz"] slave-configurations=cfg-media,cfg-untrusted,cfg-guest
+/interface wifi provisioning set [find where comment="ap2 2.4GHz"] slave-configurations=cfg-iot,cfg-media,cfg-untrusted,cfg-guest

docs/transaktionen/TEST-infra-ssid-matter-pairing.rollback.rsc

@@ -1,3 +1,18 @@
-# Rueckbau: dirtyvader-infra wieder von ap2 nehmen. Stand vor dem Change (live gelesen 2026-08-22).
-/interface wifi provisioning set [find where comment="ap2 5GHz"] slave-configurations=cfg-media,cfg-untrusted,cfg-guest
-/interface wifi provisioning set [find where comment="ap2 2.4GHz"] slave-configurations=cfg-iot,cfg-media,cfg-untrusted,cfg-guest
+# Rueckbau-VORSCHLAG fuer TEST-infra-ssid-matter-pairing (crs326-core, Scope wifi-provisioning)
+# Aus dem Snapshot vom 2026-08-22. NICHT ungeprueft deployen:
+# `add`-Zeilen legen neu an, statt zu aendern — was hier gebraucht wird,
+# ist in der Regel ein `set [find ...]`. Zeilen entsprechend anpassen.
+
+/interface wifi provisioning
+add action=create-dynamic-enabled comment="ap1 5GHz" master-configuration=\
+cfg-main-5g-ap1 radio-mac=D0:EA:11:4D:40:E5 slave-configurations=\
+cfg-media,cfg-untrusted,cfg-guest
+add action=create-dynamic-enabled comment="ap1 2.4GHz" master-configuration=\
+cfg-main-2g-ap1 radio-mac=D0:EA:11:4D:40:E6 slave-configurations=\
+cfg-iot,cfg-media,cfg-untrusted,cfg-guest
+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
+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