test: Live-E2E-Verifikation SQLCipher mit echtem Login (Test-Account)

Neuer gegateter Test (PYRAMID_LIVE_TEST=1, Windows): echter Login als
pyramidtest1, Byte-Pruefung der Platte (kein SQLite-Header, Token +
Nachricht nicht im Klartext, Positiv-Kontrolle in Klartext-DB),
Neustart aus verschluesselter DB, Logout/Re-Login, Migration einer
Klartext-DB mit echter eingeloggter Session. Zugangsdaten bleiben
ausserhalb des Repos.

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

PROGRESS.md

@@ -13,6 +13,58 @@ Schritt (und beim Abbruch mitten im Schritt den Zwischenstand). Format:
 
 ---
 
+## 2026-07-06 – Nacht-Session (A): SQLCipher mit ECHTEM Login live verifiziert (Test-Account, 2 neue E2E-Tests grün)
+
+**Erledigt:** Bernds Fokus (A) für die Nacht – die Verschlüsselung nicht nur
+behaupten, sondern mit einem echten Konto belegen. Bernd hat dafür
+Test-Accounts bereitgestellt (`~/.pyramid-autopilot/test-accounts.txt`,
+pyramidtest1/pyramidtest2 auf steggi-matrix.work – NICHT Bernds/Utas Konten).
+Neuer Live-Test `test/live_encryption_e2e_test.dart` (nur auf Windows, nur
+mit `PYRAMID_LIVE_TEST=1`, Zugangsdaten bleiben AUSSERHALB des Repos):
+
+- **Test 1 – frische Installation (grün, echter Lauf gegen den Homeserver):**
+  DB verschlüsselt angelegt (Schlüssel-Injektion wie in den Bestands-Tests),
+  echter Passwort-Login als pyramidtest1, Testraum angelegt, Nachricht mit
+  Zufalls-Marker gesendet. Danach Byte-Prüfung der Platte: Header ist NICHT
+  „SQLite format 3", und weder der echte Access-Token noch der
+  Nachrichtentext sind in `pyramid.sqlite`/`-wal` im Klartext auffindbar.
+  Gegenprobe: Raw-Query MIT Schlüssel findet beides in der Datei → die Daten
+  stecken wirklich drin, nur verschlüsselt. „Neustart" (DB neu geöffnet,
+  neuer Client): Session inkl. identischem Access-Token kommt aus der
+  verschlüsselten DB, ohne Passwort. Dann Logout → erneuter Login → alte
+  Nachricht wieder lesbar (Timeline inkl. History-Nachladen).
+- **Test 2 – Utas Update-Fall mit ECHTER Session (grün):** Klartext-DB wie
+  vor der SQLCipher-Einführung, echter Login, Nachricht. POSITIV-KONTROLLE:
+  in der Klartext-DB findet die Byte-Suche Token UND Nachricht (beweist,
+  dass die Suche Leaks erkennen würde). Dann `migratePlaintextToEncrypted`
+  (exakt der App-Codepfad): Migration grün, `.premigration`-Backup da,
+  danach ist auf der Platte nichts mehr im Klartext, Session (gleicher
+  Access-Token) und Nachricht überleben die Migration. Das war bisher der
+  große UNGETESTET-Punkt „Migration mit echter eingeloggter Session".
+- Beide Tests räumen serverseitig auf (Logout am Ende). Gesamtsuite: 32
+  Tests grün, die 2 Live-Tests skippen ohne Gate sauber. analyze sauber
+  (nur bekannter onUpdate-Hinweis).
+
+**Ehrlich abgegrenzt (bleibt UNGETESTET):** flutter_secure_storage wird im
+Host-Test umgangen (Schlüssel direkt injiziert; der Keystore-Pfad ist durch
+die echten App-Läufe Windows + Android-Emulator belegt). E2EE-verschlüsselte
+Räume kann der Host-Test nicht (kein vodozemac) – der Testraum ist
+unverschlüsselt, was für die Klartext-Suche der härtere Fall ist. Echtes
+ARM-Gerät + FCM-Push-Isolate bleiben offen (ROADMAP-Punkt weiter nicht
+abgehakt).
+
+**Offen/Nächster Schritt:** Fokus (C) Streaming 60 FPS
+(`docs/STREAMING_60FPS.md`), danach Fokus (B) Call-Logik mit beiden
+Test-Accounts.
+
+**Stolperfallen:** `Client.init(waitUntilLoadCompletedLoaded: false)` lädt
+die Raumliste ASYNCHRON – wer direkt nach dem Init `client.rooms`/
+`getRoomById` prüft, sieht eine leere Liste und meldet fälschlich
+Datenverlust. Für DB-Restaurations-Checks `waitUntilLoadCompletedLoaded:
+true` verwenden.
+
+---
+
 ## 2026-07-06 – SQLCipher auf ANDROID getestet (Emulator API 36): Neuanlage, Migration und Neustart grün
 
 **Erledigt:** Der größte offene Teil von Testplan Punkt 4