M32: Automatisches Wiederverbinden nach Verbindungsabbruch

ConnectionService: Herzschlag-Task (alle 10s /system identity) erkennt
einen Verbindungsverlust während der Sitzung; bei Ausfall Retry-Schleife
(REST->SSH, alle 5s, unbegrenzt bis Erfolg oder manuellem "Trennen").
state bleibt bewusst .connected währenddessen, damit andere Tabs nicht
auf "Nicht verbunden" umspringen — isReconnecting/reconnectAttemptCount/
secondsUntilNextReconnectAttempt treiben einen Banner im Verbinden-Tab
mit Versuchszähler + Countdown.

Live bestätigt, zusätzlich beim echten Firmware-Update-Neustart erneut
gegengetestet. README/Manual (DE+EN) aktualisiert.

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

found.md

@@ -211,6 +211,20 @@ Nachbesserung 2 (User-Feedback: auch das "Weitere Parameter"-Grid im Experte-Bea
 Build grün, alle 99 Unit-Tests grün. Bitte erneut live testen.
 
 ### 10. Selbständiger Wiederverbindungsversuch nach Disconnect
-**Status:** offen
+**Status:** fixed (live bestätigt, zusätzlich beim echten Firmware-Update-Neustart mitgetestet)
 
 Wunsch: fällt die Verbindung zum Router weg (z.B. während einer laufenden Sitzung), soll die App selbständig versuchen, die Verbindung wiederherzustellen, statt einfach im getrennten Zustand zu bleiben.
+
+Ist-Zustand vor dem Fix: `ConnectionService.state` blieb `.connected`, bis der Nutzer explizit "Trennen" klickte — es gab überhaupt keinen Mechanismus, der einen tatsächlichen Verbindungsverlust (Router aus, Kabel raus, WLAN weg) erkannt hätte. Einzelne fehlschlagende Anfragen zeigten nur lokale Fehlermeldungen pro Tab, der App-weite Zustand blieb unberührt.
+
+Umsetzung (`ConnectionService.swift`):
+- Neuer Hintergrund-Task (`healthMonitorTask`), gestartet bei jeder erfolgreichen Verbindung: alle 10s ein minimaler Lese-Test (`/system identity`, kleinstmögliches Singleton-Menü) als Herzschlag.
+- Schlägt der Herzschlag fehl: `isReconnecting = true`, danach Retry-Schleife alle 5s (REST zuerst, dann SSH-Fallback, dieselbe Reihenfolge wie ein normaler Connect) — läuft unbegrenzt weiter, bis entweder die Verbindung wiederhergestellt ist oder der Nutzer explizit "Trennen" klickt (bricht den Task sofort ab).
+- `state` bleibt bewusst durchgehend `.connected`, damit andere Tabs während eines kurzen Aussetzers nicht auf ihre "Nicht verbunden"-Platzhalter umspringen — nur `isReconnecting` (neues `@Published`) spiegelt den Zustand, sichtbar als oranger Hinweis mit Spinner oben im Verbinden-Tab ("Verbindung unterbrochen — versuche automatisch, erneut zu verbinden…").
+- Reconnect nutzt bei Erfolg denselben `finishConnecting(using:)`-Pfad wie ein normaler Connect — Geräte-/Routerboard-Info und Interface-Liste werden dabei automatisch neu geladen.
+
+Build grün, alle 99 Unit-Tests grün. Live bestätigt ("funktion").
+
+Nachbesserung 1 (User-Wunsch: "ein countdown, während wiederverbindens noch mit einbauen und wieviel versuche bereits gelaufen sind"): zwei neue `@Published`-Werte in `ConnectionService` — `reconnectAttemptCount` (hochgezählt pro REST+SSH-Runde) und `secondsUntilNextReconnectAttempt` (sekündlich runtergezählt zwischen den Versuchen, `nil` während ein Versuch tatsächlich läuft). Banner im Verbinden-Tab zeigt jetzt eine zweite, kleinere Zeile: "Versuch 3 · nächster in 4s" (bzw. "Versuch 3 …" während der Verbindungsversuch selbst läuft).
+
+Build grün, alle 99 Unit-Tests grün. Bitte nochmal live testen.