docs: Uta-Random-Logout-Fund in PROGRESS/ROADMAP protokollieren

Dokumentiert Root-Cause-Analyse und Fix aus 63e4919/9dc83f7, markiert
UNGETESTET (Pi) mit Pflicht-Praxistest am PC vor endgültigem Haken.

PROGRESS.md

@@ -13,6 +13,57 @@ Schritt (und beim Abbruch mitten im Schritt den Zwischenstand). Format:
 
 ---
 
+## 2026-07-03 – M1: Uta-Random-Logout – Ursache gefunden + Fix (UNGETESTET/Pi)
+
+**Erledigt:**
+- Alle Logout-Auslöser im Code kartiert:
+  - 3 bewusste Nutzer-Logout-Buttons in `settings_modal.dart` (alle hinter
+    Bestätigungsdialog) – kein Kandidat für "random"
+  - Der eigentliche Verdächtige: `matrix`-Paket (v6.2.0) `Client._innerSync()`
+    behandelt `M_UNKNOWN_TOKEN` vom `/sync`-Endpunkt so: bei `soft_logout: true`
+    → `_handleSoftLogout()` → versucht `refreshAccessToken()` → **das SDK
+    hatte nie einen Refresh-Token angefordert** (`client.login(...)` in
+    `login_notifier.dart` rief ohne `refreshToken: true` auf) → `refreshAccessToken()`
+    wirft sofort "No refresh token available" → Catch-Block ruft `await logout()`
+    auf: ein **echter, destruktiver Logout**, ausgelöst rein durch einen normalen
+    Soft-Logout (z. B. abgelaufenes Access-Token), ganz ohne Nutzerinteraktion.
+    Quelle: `~/.pub-cache/hosted/pub.dev/matrix-6.2.0/lib/src/client.dart:2374-2384`
+    und `:2496-2509`.
+- **Logging (Commit 63e4919):** neue `lib/core/auth_log.dart` schreibt jeden
+  Login-Status-Wechsel (`client.onLoginStateChanged`) sowie SDK-Warnungen/-Fehler
+  (`Logs().onLog`) in `auth_log.txt` im App-Support-Verzeichnis – übersteht
+  App-Neustart. Zusätzlich loggen alle 3 Nutzer-Logout-Buttons sich selbst, damit
+  sich künftig unterscheiden lässt: Nutzer-Logout vs. SDK-Auto-Logout. Reine
+  Zusatzfunktion, keine Verhaltensänderung.
+- **Fix (Commit 9dc83f7):** `client.login(...)` fordert jetzt `refreshToken: true`
+  an. Damit kann das SDK einen Soft-Logout künftig durch stillen Token-Refresh
+  überstehen, statt die Sitzung zu zerstören. Unterstützt der Server keine
+  Refresh-Tokens, bleibt das Verhalten exakt wie vorher (`response.refreshToken`
+  ist dann `null`) – der Fix kann also nichts verschlimmern.
+
+**Offen/Nächster Schritt:**
+1. **Praxistest auf dem PC (zwingend vor Haken in ROADMAP!):** Login → Nachrichten
+   senden/lesen → Logout → erneuter Login → alte verschlüsselte Nachrichten noch
+   lesbar? Dabei prüfen, ob `auth_log.txt` (App-Support-Verzeichnis) die
+   Login-Status-Wechsel sauber mitschreibt.
+2. Danach: den nächsten Punkt in M1 angehen (Push-Entschlüsselungs-Regression).
+3. **Wichtig für Bernd/Uta:** Der Fix wirkt nur für NEUE Logins. Utas bereits
+   bestehende Sitzung bekommt erst nach einem einmaligen manuellen Neu-Login
+   einen Refresh-Token und ist bis dahin weiterhin anfällig. Sobald der PC-Test
+   grün ist, sollte Uta sich einmal aus- und wieder einloggen.
+
+**Stolperfallen:**
+- Konnte auf dem Pi nicht mit echtem Login/Logout getestet werden (kein GUI,
+  kein Matrix-Testaccount zur Hand) – Fix beruht auf genauem Lesen des
+  matrix-SDK-Quellcodes, nicht auf Beobachtung im Betrieb. Deshalb zwingend
+  vor dem nächsten Haken in ROADMAP am PC nachprüfen.
+- `chat_provider.dart:42` nutzt weiterhin das deprecated `Timeline.onUpdate`
+  (Re-Entschlüsseln nach Schlüssel-Empfang) – hängt mit demselben Sync-Bereich
+  zusammen, aber bewusst nicht angefasst, um nicht zwei riskante Änderungen im
+  selben Bereich gleichzeitig ungetestet zu committen.
+
+---
+
 ## 2026-07-03 – M0 abgeschlossen: Ordnung, flutter analyze sauber, README
 
 **Erledigt:**