docs: M1-Bestandsaufnahme – 3 Punkte bereits vorhanden, SQLCipher-Lücke offen

Key-Backup-Flows und Geräteverwaltung waren schon implementiert (nur nicht
abgehakt). Neue Sicherheitslücke dokumentiert: sqlcipher_flutter_libs ist
eine ungenutzte Abhängigkeit, die Krypto-DB liegt unverschlüsselt vor.
Bewusst nicht blind gefixt (Migrationsrisiko für Bestandsinstallationen),
Frage an Bernd zur Priorität ergänzt.

PROGRESS.md

@@ -13,6 +13,56 @@ Schritt (und beim Abbruch mitten im Schritt den Zwischenstand). Format:
 
 ---
 
+## 2026-07-03 – M1: Restliche Punkte geprüft – 3 schon vorhanden, 1 echte Lücke gefunden
+
+**Erledigt:**
+- **Logout-Warnung bei fehlendem Key-Backup** (Commit b5762ea): neue Funktion
+  `isKeyBackupMissing(client)` in `bootstrap_dialog.dart` (prüft Cross-Signing +
+  `keyManager.isCached()`). Beide Logout-Dialoge in `settings_modal.dart` zeigen
+  jetzt eine rote Klartext-Warnung statt des neutralen Textes, wenn kein Backup
+  eingerichtet ist.
+- **Drei ROADMAP-Punkte waren bereits umgesetzt** (nur nicht abgehakt) – durch
+  Code-Lektüre verifiziert, nicht neu gebaut:
+  - Key-Backup einrichten/wiederherstellen: `bootstrap_dialog.dart` deckt beides
+    über den `Bootstrap`-Zustandsautomaten des matrix-SDK ab (`askNewSsss` für
+    Neueinrichtung, `askUnlockSsss` fragt auf einem neuen Gerät nach dem
+    Recovery-Key). Wird automatisch getriggert, wenn Cross-Signing fehlt
+    (`app_shell.dart:_triggerBootstrap`).
+  - Geräte-/Sessionverwaltung: `_SessionsSection` in `settings_modal.dart` –
+    Liste, Umbenennen, SAS/QR-Geräteverifizierung, Einzel- und
+    Massen-Abmeldung (mit Passwort-Reauth bei UIA-Anforderung).
+- **Echte Sicherheitslücke gefunden:** `sqlcipher_flutter_libs` ist eine
+  Abhängigkeit in `pubspec.yaml`, wird aber **nirgends im Code benutzt**.
+  `matrix_client.dart` (Haupt-App) und `background_push.dart` (Push-Hintergrund)
+  öffnen `pyramid.sqlite` beide über den normalen, unverschlüsselten
+  `sqflite`/`sqflite_common_ffi`-Factory. Die Krypto-DB (Access-Token,
+  gepickelter Olm-Account, Megolm-Sessions, komplette Nachrichtenhistorie)
+  liegt also **im Klartext** auf der Platte – nur durch Androids App-Sandbox
+  geschützt, nicht durch eine eigene Verschlüsselung.
+
+**Offen/Nächster Schritt:** SQLCipher-Anbindung NICHT blind auf dem Pi
+umgesetzt – siehe Stolperfalle unten. Braucht einen eigenen, vorsichtig
+geplanten PC-Termin: Backup der Test-DB, Migrationscode (bestehende
+Klartext-DB einmalig nach SQLCipher überführen), Test auf einem Gerät mit
+echten Daten, erst dann Rollout.
+
+**Fragen an Bernd:**
+- Priorität der SQLCipher-Lücke: Soll das vor M2 (Refactoring) angegangen
+  werden, oder reicht die App-Sandbox als Schutz erstmal aus (Angreifer bräuchte
+  Root oder physischen Zugriff + ADB, um die Datei überhaupt zu lesen)? Die
+  Migration bestehender Installationen (Uta!) ist der aufwändige/riskante Teil,
+  nicht die Verschlüsselung selbst.
+
+**Stolperfallen:**
+- Eine DB-Verschlüsselungs-Migration ist genau die Art Änderung, die laut
+  CLAUDE.md nicht "mal eben" auf dem Pi ohne Testgerät gemacht werden darf:
+  scheitert die Migration (falscher Schlüssel, falsche PRAGMA-Reihenfolge,
+  Timing zwischen Haupt-App und Push-Hintergrund-Client), sind Utas
+  Nachrichten und Krypto-Schlüssel unwiederbringlich weg. Deshalb hier nur
+  dokumentiert, nicht implementiert.
+
+---
+
 ## 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