docs: auth_log-Check 17:43-Fenster - echter 7-min-Netzausfall ohne Logout ueberstanden, Sync selbst erholt

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

PROGRESS.md

@@ -13,6 +13,34 @@ Schritt (und beim Abbruch mitten im Schritt den Zwischenstand). Format:
 
 ---
 
+## 2026-07-06 – auth_log-Check 17:43-Fenster: echter ~7-min-Netzausfall OHNE Logout überstanden (stärkster Positiv-Befund bisher)
+
+**Erledigt:** Vierte PC-Session, zuerst der Pflicht-Check der Vorsession
+(auth_log seit 17:43), Ergebnis im PC_TESTPLAN Abschnitt 1 eingetragen:
+
+- **Fenster 17:43–18:19:** `loggedIn` um 17:43:14, dann um 18:09:57 ein
+  ECHTER Verbindungsabriss zum Homeserver – „Syncloop failed: Client has
+  not connection to the server" alle 3 s bis 18:16:39 (~7 Minuten;
+  Server war zum Check-Zeitpunkt von diesem PC wieder erreichbar,
+  HTTP 200). **Kein Logout, keine Eskalation** – der Sync erholte sich
+  von selbst (WAL-Write 18:18:13 NACH der letzten Fehlerzeile, Prozess
+  durchgehend am Leben). Das ist genau der Fehlerpfad, den die
+  Uta-Logout-Fixes (63e4919/9dc83f7/891f348) absichern sollen, erstmals
+  mit einem realen Netzausfall belegt.
+- Beobachtungslauf (PID seit 17:43) läuft unangetastet weiter; kumulativ
+  heute 12:26–18:19 über 7 Starts ohne einen einzigen Random-Logout.
+
+**Offen/Nächster Schritt:** SQLCipher-Android-Test per Emulator
+(Medium Phone API 36.1 ist verfügbar, kein echtes Gerät angeschlossen) –
+Testplan Punkt 4 in `docs/SQLCIPHER_MIGRATION.md`, so weit im Emulator
+abbildbar; Rest (echtes Gerät, FCM-Push-Isolate) klar abgrenzen.
+
+**Stolperfallen:** Erfolgreiche Syncs werden NICHT geloggt – das Ende
+einer Fehlerserie im auth_log erkennt man am Ausbleiben weiterer
+Fehlerzeilen plus einem WAL-Write danach, nicht an einem „recovered"-Eintrag.
+
+---
+
 ## 2026-07-06 – Analyse-Korrektur (MediaCache NICHT risikoarm) + VoicePrefs-Vertragstests, Session-Ende sauber
 
 **Erledigt:** Abschluss der dritten PC-Session:

docs/PC_TESTPLAN.md

@@ -53,10 +53,16 @@ gelaufen – die lokale DB ist jetzt verschlüsselt (PROGRESS.md 2026-07-06).
       Fenster 17:14–17:42 sauber – kein Logout-/Fehler-Eintrag, DB-Writes
       liefen durchgehend; Lauf um 17:42 vom Autopilot beendet (Rebuild für
       den settings_encryption-Split). Beobachtung läuft seit 17:43 mit dem
-      aktuellen Code (auth_log 17:43:14 `loggedIn`, keine Migration) –
+      aktuellen Code (auth_log 17:43:14 `loggedIn`, keine Migration).
-      nächste Session bitte `auth_log.txt` auf Einträge seit 2026-07-06
+      **Check 18:19 (vierte PC-Session), Fenster 17:43–18:19:** kein Logout,
-      17:43 prüfen; erst nach einem echten Mehr-Stunden-Fenster abhaken.
+      und obendrauf der bisher wertvollste Positiv-Befund – ein ECHTER
-      Kumulativ heute: 12:26–17:42 über 6 Starts ohne einen einzigen
+      Netzausfall 18:09:57–18:16:39 (~7 min, „Client has not connection to
+      the server" alle 3 s im auth_log) wurde sauber überstanden: kein
+      Logout, keine Eskalation, Sync erholte sich von selbst (WAL-Write
+      18:18:13 nach der letzten Fehlerzeile). Genau der Fehlerpfad, den die
+      Fixes 63e4919/9dc83f7/891f348 absichern sollen. Beobachtung läuft
+      weiter; erst nach einem echten Mehr-Stunden-Fenster abhaken.
+      Kumulativ heute: 12:26–18:19 über 7 Starts ohne einen einzigen
       Random-Logout)
 - [ ] Ergebnis als „Härtetest"-Eintrag in PROGRESS.md dokumentieren
       (= ROADMAP-M1-Punkt „Härtetest dokumentieren" abhaken)