Kein ESP32: die -infra-SSID ist damit der Standardweg

User-Entscheid 2026-08-22: es wird kein ESP32 als ESPHome-BT-Proxy
angeschafft. ble_proxy bleibt an, ist aber wirkungslos -- HA hat keine
connectable BLE-Quelle (Shellys: slots=0 auf allen dreien, gemessen) und
bekommt keine. Konsequenz, die beim naechsten Thread-Geraet zaehlt: der Weg
ist wieder die temporaere -infra-SSID. Runbook entsprechend von "Plan B" auf
Standardweg umgeschrieben, Blocker-Abschnitt als erledigt markiert (aber mit
dem Hinweis, dass Regel 3 jederzeit wieder greifen kann).

Neuer Nebenbefund unter TP12.1, bewusst als thread-, nicht ipv6-Thema
markiert: die Knoten @1:a (Diele OG/Treppenauge), @1:f und @1:10 flappen seit
Stunden (Resolving address is unreachable -> offline grace period expired),
waehrend die uebrigen ~20 stabil sind -- also kein Fabric-Problem. Vor jeder
Diagnose die Sonderlage von heute abziehen: OTBR-Neustart um 17:33 und ap1
zwischenzeitlich vom Netz. Erst pruefen, ob es danach noch besteht.

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

docs/matter-pairing-infra-ssid-runbook.md

@@ -5,25 +5,28 @@ OpenThread-Border-Router auf **demselben L2-Link** sitzen. Dann wirbt der OTBR d
 *und* Route in den Thread-OMR-Prefix per RA, iOS wertet beides aus — und die fehlende IPv6-Route zwischen
 VLAN10 und VLAN20 (**TP12.1**) wird gar nicht erst berührt.
 
-**Status:** 🟠 vorbereitet 2026-08-22, **nicht deployt** — s. Blocker.
+**Status:** ✅ **einmal durchgespielt am 2026-08-22** (TIMMERFLOTTE angelernt, danach zurückgebaut).
+Dies ist ab jetzt **der Standardweg** für jedes neue Thread-Gerät, nicht der Plan B.
 
-> **Erst prüfen, ob dieses Runbook überhaupt nötig ist.** Seit 2026-08-22 läuft der Matter-Server mit
-> `ble_proxy: true` (`BLE is enabled (proxy mode)`). Wenn HA eine **connectable** BLE-Quelle hat,
-> kommissioniert HA selbst und das Telefon wird nicht gebraucht. Shelly-BLE-Proxies sind
-> **Advertisement-Scanner ohne GATT** und reichen dafür vermutlich nicht; ein ESP32 als
-> ESPHome-BT-Proxy (`active: true`) reicht. **Dieses Runbook ist der Plan B.**
+> **Warum es keinen bequemeren Weg gibt.** Der Matter-Server läuft seit 2026-08-22 mit
+> `ble_proxy: true` (`BLE is enabled (proxy mode)`, Handshake steht). Damit könnte **HA selbst**
+> kommissionieren und das Telefon wäre raus — es fehlt nur eine **connectable** BLE-Quelle.
+> Die Shellys sind es nicht: gemessen `slots: 0, free: 0` auf allen dreien, also reine
+> Advertisement-Scanner ohne GATT. Ein ESP32 als ESPHome-BT-Proxy wäre die Lösung, ist aber per
+> **User-Entscheid 2026-08-22 abgelehnt**. Bleibt dieses Runbook — oder TP12.1 wirklich bauen.
+
+> ✅ **Was seit dem ersten Durchlauf leichter ist:** `cfg-infra`, `dp-infra` und `sec-infra` bleiben
+> auf User-Wunsch dauerhaft am Manager stehen (inaktiv, in keiner `provisioning`-Zeile). Der Change
+> ist deshalb wirklich nur noch das Hinzufügen von `cfg-infra` zu zwei Slave-Listen.
 
 ---
 
-## 🔴 Blocker: eine offene Transaktion je Gerät
+## ~~🔴 Blocker: eine offene Transaktion je Gerät~~ — erledigt 2026-08-22
 
-Auf `crs326-core` ist **`TEST-ether3-trunk-ap1-sideboard`** offen (Scope `bridge-vlan`, Frist 2026-09-04,
-TP25-Standorttest). `gc-transaktion.py begin` verweigert deshalb eine zweite Akte auf demselben Gerät
-(Regel 3). Vor dem Deploy also **eines von beiden**:
-
-- die ether3-Akte `commit`en oder `rollback`en — sie gehört TP25, das ist Christophs Entscheidung; **oder**
-- bewusst ohne Transaktion deployen — dann ist es **undokumentierter Drift**, genau das, was
-  `docs/transaktionen/README.md` abschaffen wollte. Nicht empfohlen.
+Die ether3-Akte wurde am 2026-08-22 zurückgerollt, `crs326-core` ist transaktionsfrei — der Blocker
+besteht nicht mehr. **Er kann jederzeit wiederkommen:** Regel 3 erlaubt genau *eine* offene Akte je
+Gerät. Steht beim nächsten Mal etwas anderes auf `crs326-core` offen, muss das erst geschlossen werden.
+`gc-transaktion.py status` sagt es in einer Zeile.
 
 ## Vorbedingungen (alle live geprüft 2026-08-22 ✅)