chore(docs): update roadmap and add Sync Fix report, remove desktop-app from compose config

- Marked Phase 3 of roadmap as complete and adjusted next steps.
- Added detailed report documenting the Sync type mismatch resolution.
- Commented out the `desktop-app` service from `dc-gui.yaml`.

docs/01_Architecture/MASTER_ROADMAP_2026_Q1.md

@@ -45,12 +45,12 @@ Wir validieren die gesamte Architektur-Kette (Frontend -> Gateway -> Service ->
 
 ---
 
-### PHASE 3: Offline & Sync (IN PROGRESS)
+### PHASE 3: Offline & Sync (ABGESCHLOSSEN)
 *Ziel: Datenkonsistenz auch bei Netzwerk-Verlust.*
 
 #### 🤝 Joint Task Force (Backend & Frontend)
 *   [x] **Sync-Protokoll:** `PingEvent` Contract definiert.
-*   [ ] **Sync-Fix (CRITICAL):** Typ-Mismatch beheben! Backend erwartet `Long` Timestamp, Frontend muss sicherstellen, dass kein String-Cursor gesendet wird.
+*   [x] **Sync-Fix (CRITICAL):** Typ-Mismatch behoben! Backend und Frontend nutzen nun konsistent `since: Long`.
 *   [x] **Web-App Sync:** SQLDelight Integration vorbereitet.
 
 ---
@@ -63,6 +63,5 @@ Wir validieren die gesamte Architektur-Kette (Frontend -> Gateway -> Service ->
 5.  [x] In Zipkin ist der komplette Request-Trace (Frontend -> Gateway -> Service -> DB) sichtbar.
 
 ## 4. Next Steps (Q1/2026)
-1.  **Sync-Fix:** Typ-Sicherheit zwischen Frontend und Backend herstellen.
-2.  **Entries Service:** Beginn der Implementierung des ersten echten Fach-Services ("Nennungen").
-3.  **System Hardening:** Keycloak Production-Config (kein `start-dev`).
+1.  **Entries Service:** Beginn der Implementierung des ersten echten Fach-Services ("Nennungen").
+2.  **System Hardening:** Keycloak Production-Config (kein `start-dev`).

docs/90_Reports/2026-02-01_Sync_Fix_Report.md

@@ -0,0 +1,33 @@
+---
+type: Report
+date: 2026-02-01
+author: Curator
+status: FINAL
+---
+
+# Report: Fix Sync Type Mismatch (String vs Long)
+
+## 1. Problembeschreibung
+Es wurde eine kritische Inkonsistenz im Delta-Sync-Mechanismus zwischen Frontend und Backend festgestellt.
+*   **Frontend:** Der generische `SyncManager` nutzte einen String-Cursor (UUIDv7), was zu einem Typ-Fehler führte.
+*   **Backend:** Der `PingController` erwartete strikt einen `Long` (Timestamp) für den Parameter `lastSyncTimestamp`.
+
+## 2. Durchgeführte Maßnahmen
+### 2.1 Backend (`ping-service`)
+*   **Parameter-Umbenennung:** Der Parameter im `PingController` wurde von `lastSyncTimestamp` zu `since` umbenannt, um der Konvention des Frontend-SyncManagers zu entsprechen.
+*   **Tests:** Unit- und Integrationstests (`PingControllerTest`) wurden aktualisiert.
+
+### 2.2 Frontend (`meldestelle-portal`)
+*   **Repository-Anpassung:** `PingEventRepositoryImpl` holt nun explizit den `last_modified` Timestamp aus der Datenbank (via neuer SQL-Query `selectLatestPingEventTimestamp`).
+*   **Typ-Konvertierung:** Der Timestamp wird als String an den `SyncManager` übergeben, der ihn als URL-Parameter anhängt. Spring Boot konvertiert diesen String automatisch zurück in einen `Long`.
+
+### 2.3 Contracts (`ping-api`)
+*   Das Interface `PingApi` wurde aktualisiert: `syncPings(since: Long)`.
+
+## 3. Ergebnis
+*   Die Typ-Sicherheit ist hergestellt.
+*   Tests im Backend laufen erfolgreich durch.
+*   Der Sync-Mechanismus ist nun robust und bereit für den produktiven Einsatz.
+
+## 4. Status
+✅ **RESOLVED**