docs: M2-Modul-Schnitt definieren (docs/M2_MODULE_SCHNITT.md)

Öffentliche Schnittstellen für call_signaling, voice_channel, call_ui,
settings, verification, storage u.a. entworfen. Wichtigste Erkenntnis:
"Calls" ist architektonisch zwei getrennte Module (Matrix-VoIP vs.
LiveKit-SFU-Voice-Channels), keine gemeinsame Fassade. Korrigiert
nebenbei einen falschen Ist-Analyse-Befund (rooms_provider-Import war
fälschlich als toter Code eingestuft).

PROGRESS.md

@@ -13,6 +13,62 @@ Schritt (und beim Abbruch mitten im Schritt den Zwischenstand). Format:
 
 ---
 
+## 2026-07-03 – M2: Modul-Schnitt definiert (docs/M2_MODULE_SCHNITT.md)
+
+**Erledigt:** Ausgehend von der Ist-Analyse (Eintrag darunter) die konkreten
+Modul-Grenzen + öffentliche Schnittstellen entworfen, dokumentiert in
+`docs/M2_MODULE_SCHNITT.md`. Reine Planung, kein Code geändert. Wichtigste
+Erkenntnis beim genaueren Lesen von `voip_manager.dart` und
+`livekit_call_manager.dart`: „Calls" ist architektonisch **kein einzelnes
+Feature**, sondern zwei unabhängige Mechanismen, die getrennt bleiben sollten:
+- `PyramidVoipManager` = natives Matrix-1:1-VoIP (`m.call.*`, direkte
+  WebRTC-Peer-Connection, kein SFU)
+- `LiveKitCallManager` = SFU-basierte Voice-Channels (LiveKit-Raum, Presence
+  via Matrix-State-Event, Screensharing, Mehrpersonen) – das ist der
+  Discord-artige Kanal aus M3/M4
+
+Modul-Liste im Dokument: `call_signaling`, `voice_channel`, `call_ui`,
+`settings` (aufgesplittet in Sektionsdateien), `verification` (neu, aus
+Settings herausgelöst – SAS/QR/Recovery-Key), `storage` (Ausbau der
+bestehenden `settings_prefs.dart`-Abstraktion zur Pflicht), `auth` (schon
+relativ sauber, kein akuter Bedarf), `push` (schon getrennt, eigener
+`sqflite`-Zugriff in `background_push.dart` ist bewusst so, kein
+Refactoring-Kandidat), `chat_timeline`/`rooms` (niedrigste Priorität, da
+strukturell am wenigsten verwoben – Hauptproblem dort ist Dateigröße/Duplikate,
+nicht Kopplung). Jeweils mit Dart-Interface-Skizze bzw. Datei-Zielliste.
+
+Empfohlene Umsetzungsreihenfolge: 1) Call-Pilot (`call_signaling` +
+`voice_channel` + `call_ui`, deckt gleich zwei ROADMAP-Punkte ab), 2)
+`settings_modal.dart` aufsplitten (geringes Risiko, reine Datei-Teilung),
+3) `verification` herauslösen, 4) `storage`-Fassade schrittweise erzwingen,
+5) `chat_timeline`/`rooms` zuletzt.
+
+**Offen/Nächster Schritt:** Wartet auf Bernds Entscheidung, ob der Call-Pilot
+wie vorgeschlagen als Nächstes umgesetzt wird (siehe Frage unten). Erst danach
+den ROADMAP-Punkt „Call-Schicht entwirren" wirklich anfassen – das ist die
+erste Stelle mit echtem Verhaltensrisiko in M2 (CLAUDE.md: nach Refactoring-
+Schritten immer App starten + Kernflows prüfen, hier zusätzlich brisant, weil
+GUI-Test auf dem Pi nicht möglich ist).
+
+**Stolperfallen:** Der erste Ist-Analyse-Durchgang (Subagent) hatte einen
+falschen Befund (`rooms_provider.dart`-Import in `app_state.dart` sei toter
+Code) – beim genaueren Lesen für den Modul-Schnitt widerlegt
+(`voiceParticipantsProvider` nutzt `roomListProvider` daraus). Bereits im
+Ist-Analyse-Eintrag korrigiert. Lehre: Subagent-Ist-Analysen sind ein guter
+Startpunkt, aber vor jedem darauf aufbauenden Schritt einzelne Befunde
+gegenlesen, nicht blind übernehmen.
+
+**Fragen an Bernd:**
+- Call-Pilot wie in `docs/M2_MODULE_SCHNITT.md` vorgeschlagen (zuerst
+  `call_signaling`/`voice_channel`/`call_ui` entwirren) als nächster
+  Umsetzungsschritt in Ordnung, oder lieber zuerst `settings_modal.dart`
+  aufsplitten (geringeres Risiko, aber deckt keinen ROADMAP-Punkt aus M2
+  direkt ab)? Ohne GUI-Zugriff auf dem Pi kann der riskantere Call-Umbau
+  hier ohnehin nicht praktisch getestet werden – das spricht eher für
+  „auf dem PC anfangen", falls Zeitdruck besteht.
+
+---
+
 ## 2026-07-03 – M2: Ist-Analyse der Architektur geschrieben
 
 **Erledigt:** M1 hat aktuell keinen auf dem Pi bearbeitbaren Punkt mehr offen
@@ -43,11 +99,13 @@ gefunden:
   zusammen mit der Call-Fassade angegangen werden, nicht isoliert.
 - **`core/` ist nicht rein generisch:** importiert Feature-Code direkt
   (`app.dart`/`router.dart` → `features/auth/*`, `matrix_client.dart` instanziiert
-  `PyramidVoipManager` direkt, `app_state.dart` importiert `rooms_provider.dart`
-  augenscheinlich ungenutzt – vermutlich Altlast). `app_state.dart` selbst ist ein
-  Sammelbecken für Theme-, Call-, Voice-, Share-Target- und Spaces-Provider aus
-  praktisch allen Features – zentraler Kopplungspunkt, der jedem Modulschnitt
-  im Weg steht.
+  `PyramidVoipManager` direkt). `app_state.dart` selbst ist ein Sammelbecken für
+  Theme-, Call-, Voice-, Share-Target- und Spaces-Provider aus praktisch allen
+  Features – zentraler Kopplungspunkt, der jedem Modulschnitt im Weg steht.
+  (Korrektur beim genaueren Hinsehen für den Modul-Schnitt-Punkt: der
+  `rooms_provider.dart`-Import dort ist entgegen der ersten Vermutung KEIN
+  toter Altlast-Import – `voiceParticipantsProvider` nutzt `roomListProvider`
+  daraus. Zeigt: Subagent-Befunde vor dem Weiterbauen selbst nachprüfen.)
 - **Keine gemeinsame Storage-Schnittstelle:** `SharedPreferences.getInstance()`
   wird an 12 Stellen direkt aufgerufen, obwohl `core/settings_prefs.dart` bereits
   eine `StateNotifier`-Abstraktion (`BoolPref`, `StringSetPref`) anbietet – wird