bugs.md: Nutzer-gemeldeter Hänger beim Anlegen eines DHCP-Pools

Neuer Eintrag #11: Nutzer-Meldung + Code-Audit-Befund (plausibler
Kandidat: SSHTransport.connect() hat keinen Timeout, jeder erste
Schreibvorgang pro Session loest ueber ensureSessionBackup() eine
dedizierte SSH-Verbindung aus - haengt die, blockiert die UI
unbegrenzt). Noch nicht bestaetigt, Status offen.

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

bugs.md

@@ -318,3 +318,39 @@ entfernt.
 Button) ist nach diesem zweiten Code-Review-Durchgang funktional plausibel, aber noch nie
 tatsächlich in der App-UI durchgeklickt worden — dafür bräuchte es einen Live-Test durch den
 Nutzer, da UI-Automatisierung hier nicht verfügbar ist.
+
+---
+
+## 2026-09-17 (Nachtrag 4: Nutzer-gemeldet, live in der App)
+
+### 11. Hänger beim Anlegen eines DHCP-Pools
+**Status:** offen (Nutzer-Meldung, Ursache noch nicht bestätigt — siehe Code-Audit unten)
+**Confidence:** mittel (plausibler Root-Cause-Kandidat per Code-Audit gefunden, noch nicht live
+reproduziert/bestätigt, da UI-Automatisierung nicht verfügbar ist)
+
+Nutzer-Meldung: "Hänger beim Anlegen eines DHCP-Pools" — App bleibt beim Anlegen eines
+`/ip pool`-Eintrags hängen. Noch keine weiteren Details bekannt (welcher Bereich — Experte-Tab
+oder Einrichten-Assistent LAN-Schritt; ob sich die App von selbst erholt oder ein Neustart nötig
+ist; ob vorher eine Fehlermeldung erscheint).
+
+**Code-Audit-Befund, plausibler Kandidat:** `SSHTransport.connect()` (`SSHTransport.swift`) setzt
+für den `Citadel.SSHClient.connect(...)`-Aufruf **keinerlei Timeout** — im Gegensatz zu
+`RestTransport`, das für jede Anfrage `request.timeoutInterval = 5` explizit setzt. Jeder erste
+Schreibvorgang einer Session (egal ob Experte-Tab oder Einrichten-Assistent) löst zuerst
+`ensureSessionBackup()` aus, was `BackupService.createBackup(for:)` über eine **dedizierte, neue
+SSH-Verbindung** aufruft (`BackupService.swift`, "always over SSH"-Muster). Hängt dieser
+`connect()`-Aufruf (z.B. durch einen kurzen Netzwerk-Aussetzer oder einen unter Last
+langsam/nicht antwortenden Router — der hAP-lite-Testrouter ist mit MIPS 24Kc/650MHz/1 Kern sehr
+schwach, in dieser Session bereits bis 80% CPU-Last beobachtet), gibt es keinen Timeout, der die
+App wieder freigibt — `isApplying`/der Ladeindikator bliebe dann unbegrenzt aktiv, exakt das vom
+Nutzer beschriebene Bild eines "Hängers" ohne Fehlermeldung.
+
+Noch nicht bestätigt, ob das tatsächlich die Ursache ist — nur ein durch Code-Lesen gefundener,
+plausibler Kandidat, kein reproduzierter Fehler. Gleiche Lücke beträfe auch `ConnectionService.
+applyViaSSH`/`flushConnections` (beide nutzen ebenfalls `SSHTransport.connect()` ohne Timeout) und
+`UpdateService`/`FactoryResetService`/`NetworkToolsService`, die dieselbe Transport-Klasse nutzen.
+
+**Fix-Ansatz (noch nicht umgesetzt):** `SSHTransport.connect()` mit einem Timeout umgeben (z.B.
+`withThrowingTaskGroup`/`Task.sleep`-Race, ähnlich wie RESTs `timeoutInterval`), damit ein
+hängender Verbindungsaufbau nach einigen Sekunden als Fehler zurückkommt statt die UI unbegrenzt
+zu blockieren.