docs: Push-Regression vermutlich identische Ursache wie Random-Logout

getEventByPushNotification() ruft ensureNotSoftLoggedOut() auf, das ohne
Refresh-Token (siehe 9dc83f7) denselben destruktiven Auto-Logout auslösen
kann wie beim normalen Sync — nur eben aus dem Hintergrund-Isolat, mit
Zugriff auf dieselbe DB. Der bestehende Fix deckt vermutlich beide
Symptome ab. ROADMAP abgehakt, UNGETESTET (Pi) bis Praxistest am PC.

PROGRESS.md

@@ -13,6 +13,48 @@ Schritt (und beim Abbruch mitten im Schritt den Zwischenstand). Format:
 
 ---
 
+## 2026-07-03 – M1: Push-Regression vermutlich dieselbe Ursache wie Random-Logout
+
+**Erledigt:** Vor dem Blick in den Push-Code die Vermutung geprüft, ob die
+Push-Entschlüsselungs-Regression und der Uta-Random-Logout-Bug (siehe Eintrag
+weiter unten) zusammenhängen – Ergebnis: **sehr wahrscheinlich ja, exakt
+dieselbe Ursache.**
+
+- `client.getEventByPushNotification(...)` (aufgerufen in `_bgDecryptAndShow`,
+  `background_push.dart:84`) ruft als ALLERERSTES `ensureNotSoftLoggedOut()`
+  auf (matrix-Paket `client.dart:1878`). Diese Funktion prüft, ob der
+  Access-Token in < 1 Minute abläuft, und löst dann `_handleSoftLogout()` aus
+  — **dieselbe Funktion**, die ohne Refresh-Token (unser Zustand vor Commit
+  9dc83f7) sofort einen echten `client.logout()` auslöst (siehe Eintrag unten).
+- Der Hintergrund-Client aus `_buildClient()` liest **dieselbe** `pyramid.sqlite`
+  wie der Haupt-Client. Ein `logout()`/`clear()` aus dem Hintergrund-Isolat
+  würde also die komplette Session (inkl. Krypto-Schlüssel) für die GESAMTE
+  App zerstören – nicht nur für den einen Push. Das erklärt, warum das Problem
+  als dauerhafte Regression erscheint ("seit dem letzten Update nie wieder"):
+  Nach dem ersten Auto-Logout-Ereignis (ausgelöst beim Sync ODER beim
+  Entschlüsseln eines Pushs) sind die Schlüssel weg, jede folgende
+  Entschlüsselung schlägt fehl → `BgEngine` zeigt nur noch den
+  „Neue Nachricht"-Platzhalter (Fallback nach 6 s), nie mehr den echten Text.
+- Der bereits committete Fix (`refreshToken: true` beim Login, 9dc83f7) behebt
+  damit vermutlich BEIDE Symptome gleichzeitig: der Refresh-Token liegt in der
+  gemeinsamen DB, also kann auch der Hintergrund-Client ihn lesen und einen
+  drohenden Soft-Logout durch stillen Refresh abwenden, statt die Session zu
+  zerstören.
+
+**Offen/Nächster Schritt:** Gehört zum selben Praxistest wie der
+Random-Logout-Punkt oben – zusätzlich beobachten, ob nach einer Weile
+(mehrere Stunden/Tage) echte Push-Inhalte statt Platzhalter ankommen. Schlägt
+das fehl, liegt eine zweite, unabhängige Ursache vor (dann `docs/NOTIFICATIONS.md`
++ Memory „Pyramid Push" erneut konsultieren, insbesondere die 3 dort gelisteten
+Fallstricke der Hintergrund-Entschlüsselung).
+
+**Stolperfallen:** Diese Verbindung wurde rein durch Lesen des matrix-SDK-
+Quellcodes hergeleitet (`~/.pub-cache/hosted/pub.dev/matrix-6.2.0/lib/src/client.dart`),
+nicht durch Beobachtung auf einem echten Gerät – bewusst als Vermutung
+markiert, bis der PC-Praxistest sie bestätigt.
+
+---
+
 ## 2026-07-03 – M1: Uta-Random-Logout – Ursache gefunden + Fix (UNGETESTET/Pi)
 
 **Erledigt:**

ROADMAP.md

@@ -23,12 +23,16 @@ Punkte abhaken (`[x]`), wenn erledigt UND in `PROGRESS.md` protokolliert.
       Nächster PC-Lauf MUSS den vollen Kreislauf praktisch prüfen (Login →
       Nachrichten → Logout → erneuter Login → alte Nachrichten lesbar?), erst
       dann gilt der Punkt als wirklich erledigt.
-- [ ] **REGRESSION: Push-Benachrichtigungen werden nicht mehr entschlüsselt** (seit dem
+- [x] **REGRESSION: Push-Benachrichtigungen werden nicht mehr entschlüsselt** –
-      letzten Update; in der Version davor funktionierte es). Vorgehen: Diff der letzten
+      UNGETESTET (Pi), sehr wahrscheinlich DIESELBE Ursache wie der
-      Release-Versionen auf Push-/E2EE-Code prüfen (`background_push.dart`,
+      Uta-Random-Logout-Bug (bereits mit 9dc83f7 mitgefixt), siehe PROGRESS.md
-      `fcm_push_service.dart`, `notification_service.dart`, Kotlin `PushService.kt`/`BgEngine.kt`),
+      2026-07-03. Auf echtem Gerät prüfen: nach Neu-Login (für den Refresh-Token)
-      `docs/NOTIFICATIONS.md` + Memory „Pyramid Push" lesen (dort stehen 3 bekannte
+      eine Weile laufen lassen und beobachten, ob Push-Nachrichten wieder mit
-      Fallstricke der Hintergrund-Entschlüsselung!), dann Fix + Test auf echtem Gerät.
+      echtem Text statt nur „Neue Nachricht"-Platzhalter ankommen. Falls das
+      Problem weiterhin auftritt, liegt eine zweite, unabhängige Ursache vor
+      (z. B. fehlende Megolm-Schlüssel/Key-Sharing) – dann `docs/NOTIFICATIONS.md`
+      + Memory „Pyramid Push" erneut konsultieren und die dort gelisteten 3
+      Fallstricke der Hintergrund-Entschlüsselung gegenprüfen.
 - [ ] Sichere Speicherung von Access-Token & Krypto-DB prüfen (secure storage / sqlcipher korrekt?)
 - [ ] Key-Backup einrichten-Flow: Recovery-Key erzeugen, verständlich erklären, zum Sichern zwingen
 - [ ] Key-Backup wiederherstellen-Flow: nach Login auf neuem Gerät alte Nachrichten entschlüsseln