docs: Session-Check – Call-Fassade und M1-Punkte weiterhin PC-only/Bernd-Entscheidung

Keine neue Information seit letzter Session: SQLCipher und Härtetest brauchen
PC/GUI, Call-Schicht-Fassade ist kein reiner Datei-Split (Singleton +
WebRTCDelegate + Timer-Polling) und wartet weiterhin auf Bernds Go, um nicht
blind ein produktiv genutztes Call-Feature zu riskieren.

PROGRESS.md

@@ -13,6 +13,56 @@ Schritt (und beim Abbruch mitten im Schritt den Zwischenstand). Format:
 
 ---
 
+## 2026-07-03 – Session-Check: weiterhin kein sicher bearbeitbarer Punkt auf dem Pi
+
+**Erledigt:** Vor dem Weiterarbeiten Arbeitszyklus komplett durchlaufen: `PROGRESS.md`
++ `ROADMAP.md` gelesen, `flutter analyze` (weiterhin sauber, nur der eine bekannte
+Hinweis in `chat_provider.dart:42`), `git status` (sauber, `master` = `origin/master`),
+`flutter doctor` erneut geprüft (Android-SDK, Chrome, Linux-Desktop-Toolchain fehlen
+weiterhin auf diesem Pi – keine GUI möglich). Damit alle offenen Punkte in M1/M2
+gegengeprüft:
+- M1 „SQLCipher" und „Härtetest dokumentieren": unverändert PC-only (siehe Einträge
+  weiter unten), keine neue Information seit letzter Session.
+- M2 „Call-Schicht entwirren": zum Einstieg `core/voip_manager.dart` (538 Zeilen)
+  gelesen, um eine Fassade zu entwerfen. Ergebnis: Das ist **kein** Datei-Split wie die
+  letzten 5 Gott-Datei-Umbauten (dort: reines `part`/`part of`, null Logikänderung,
+  automatisiert byte-genau verifizierbar). `PyramidVoipManager` ist ein Singleton
+  (`_instance`), der gleichzeitig `ChangeNotifier` UND die vom matrix-SDK verlangte
+  `WebRTCDelegate`-Schnittstelle implementiert, mit Timer-basiertem Renderer-Polling,
+  impliziten Reihenfolgen bei Mute/Unmute/Screenshare und einem `MediaDevicesWrapper`,
+  der direkt auf private Felder des Managers zugreift. Eine Fassade davor UND die
+  Umstellung der 7 Importstellen lässt sich nicht mehr rein mechanisch verifizieren –
+  echtes Risiko für Verhaltensänderung an Calls, die echte Nutzer (Uta) im Einsatz
+  haben. Genau das hatte die vorige Session bereits zweimal als „erste Stelle mit
+  echtem Verhaltensrisiko in M2" geflaggt und Bernds Entscheidung dazu angefragt
+  (siehe „Fragen an Bernd" weiter unten) – hier bestätigt und bewusst NICHT
+  eigenmächtig angefasst, weil auf diesem Pi ohnehin kein GUI-Test möglich ist, um
+  eine Regression aufzufangen.
+
+**Offen/Nächster Schritt:** Es gibt aktuell **keinen** ROADMAP-Punkt in M1/M2, der auf
+diesem Pi ohne (a) Bernds Antwort auf die Call-Pilot-Frage oder (b) echten PC/GUI-Zugriff
+sicher bearbeitet werden kann. Nächster sinnvoller Schritt ist entweder ein PC-Termin
+(Härtetest + SQLCipher-Migrationsplanung + Call-Fassade mit echtem Test) oder Bernds
+kurze Antwort auf die unten stehende Frage, damit die nächste Pi-Session direkt starten
+kann.
+
+**Stolperfallen:** Keine neuen – Bestätigung, dass die Vorsicht der letzten Session
+richtig war: „sieht aus wie ein weiterer Datei-Split" ist bei der Call-Schicht trügerisch,
+weil Singleton-Lifecycle + SDK-Delegate-Vertrag + Timer-Polling nicht mit einem
+Textvergleich absicherbar sind wie bei reinen `part`/`part of`-Umbauten.
+
+**Fragen an Bernd:** Unverändert offen (wiederholt aus den letzten beiden Einträgen,
+damit sie nicht übersehen wird):
+1. Call-Pilot (Fassade für `voip_manager.dart`/`livekit_call_manager.dart`) jetzt
+   angehen (nur auf einem PC mit echtem Test), oder erstmal zurückstellen?
+2. SQLCipher-Verschlüsselung der lokalen DB: Priorität vor M2, oder reicht die
+   App-Sandbox als Schutz vorerst?
+Ohne eine dieser beiden Antworten bleibt der Pi bei jedem weiteren Durchlauf an
+derselben Stelle stehen – ein kurzer PC-Termin für Härtetest + Call-Pilot würde
+gleich mehrere blockierte Punkte auf einmal lösen.
+
+---
+
 ## 2026-07-03 – M2: Gott-Datei `chat_view.dart` aufgeteilt (6 Dateien) – ROADMAP-Punkt abgehakt
 
 **Erledigt:** Fünfter und letzter Durchgang derselben `part`/`part of`-Technik: