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

@@ -658,7 +658,26 @@ FT kaschierte das bisher als „Roaming" statt „schwache Abdeckung".
   2026.06, hier 2026.8.3). Dann kommissioniert **HA selbst** über seinen Bluetooth-Stack; das Telefon ist
   raus und die VLAN-Grenze wird nie berührt. Braucht eine **connectable** BLE-Quelle — Shelly-Proxies sind
   reine Advertisement-Scanner (kein GATT), ein **ESP32 als ESPHome-BT-Proxy** (`active: true`) reicht.
-  Der **ESPHome Device Builder ist bereits installiert**. Damit wird TP12.1 für Matter **optional**.
+  Der **ESPHome Device Builder ist bereits installiert**. Damit wäre TP12.1 für Matter **optional**.
+  🔴 **User-Entscheid 2026-08-22: ESP32 wird NICHT angeschafft.** Damit bleibt `ble_proxy` zwar an
+  (schadet nicht, kostet nichts), ist aber **wirkungslos** — HA hat keine connectable BLE-Quelle und
+  wird auch keine bekommen. **Konsequenz, die man beim nächsten Thread-Gerät kennen muss:** der Weg ist
+  dann wieder die temporäre `-infra`-SSID nach dem Runbook. Die ist inzwischen ein Zweizeiler, weil
+  `cfg-infra`/`dp-infra`/`sec-infra` am Manager stehen bleiben — aber sie ist jedes Mal ein
+  Config-Change am Core plus eine Transaktion. Wer das dauerhaft loswerden will, muss **TP12.1 bauen**
+  (v6-Firewall zuerst); ein dritter Weg ist damit nicht mehr vorgesehen.
+
+- 🔎 **Nebenbefund 2026-08-22, gehört zur Thread-Gesundheit, NICHT zu IPv6:** drei Matter-Knoten
+  flappen dauerhaft — **`@1:a` („Diele OG/Treppenauge")**, **`@1:f`** und **`@1:10`**. Muster im
+  Matter-Server-Log: `IpServiceStatus … Resolving (address is unreachable)`, dann
+  `offline grace period expired, marking unavailable`, im Abstand von 15–30 Minuten, über Stunden.
+  Die übrigen ~20 Knoten sind stabil, es ist also **kein** Border-Router- oder Fabric-Problem.
+  ⚠️ **Vor einer Diagnose die Sonderlage von heute abziehen:** der OTBR ist am 2026-08-22 um 17:33
+  neu gestartet (Knoten fielen kurzzeitig von OMR `fd92:…` auf Mesh-Local `fd66:…` zurück), und ap1
+  war zwischenzeitlich vom Netz. Erst nachsehen, ob das Flappen **danach** noch besteht — sonst
+  diagnostiziert man das Nachbeben eines Umbaus. Erste Verdachtsrichtungen, wenn es bleibt:
+  Thread-Routing/Parent-Wechsel dieser drei Knoten, schwache Funkstrecke zum nächsten Router-Knoten,
+  oder eine ICD-/Sleepy-End-Device-Eigenheit dieser Geräteklasse.
 - **Abh.:** hängt an nichts. **Blockiert nichts** — außer künftige Thread-Geräte, solange weder
   `ble_proxy` noch die `-infra`-SSID steht. Reihenfolge innerhalb des TP ist zwingend:
   **v6-Firewall nachbauen → dann erst Adressen vergeben.** Gehört unter TP12 (Gesamtkonzept 3 Standorte),