feat(sync): implement Delta-Sync API and update clients to support offline-first workflow

Added `/ping/sync` endpoint with timestamp-based Delta-Sync functionality to efficiently support offline-first clients. Extended `PingApi` and frontend clients (`PingApiClient`, `PingApiKoinClient`) with `syncPings`. Updated repository, service, and controller logic for sync handling, including new JPA query `findByCreatedAtAfter`. Adjusted test doubles and completed unit tests for backend and frontend alignment. Documented sync approach and API usage.

docs/90_Reports/Backend_Status_Report_01-2026.md

@@ -2,68 +2,47 @@
 type: Report
 status: FINAL
 author: Senior Backend Developer
-date: 2026-01-16
-context: Phase 1 - Backend Hardening
+date: 2026-01-17
+context: Phase 3 - Sync Implementation
 ---
 
-# Backend Status Report: Phase 1 (Hardening) abgeschlossen
+# Backend Status Report: Phase 3 (Sync) abgeschlossen
 
 ## 1. Zusammenfassung
-Die Phase 1 der "Operation Tracer Bullet" wurde erfolgreich abgeschlossen. Das Backend (Gateway und Ping-Service) ist nun gehärtet, sicher und vollständig in die Infrastruktur integriert.
+Die Phase 3 der "Operation Tracer Bullet" wurde erfolgreich abgeschlossen. Der `PingService` wurde um Delta-Sync-Funktionalität erweitert, um Offline-First-Clients effizient zu unterstützen.
 
 **Wichtigste Errungenschaften:**
-*   **Gateway:** Vollständige Migration auf Spring Cloud Gateway (WebFlux) mit OAuth2 Resource Server Security.
-*   **Ping Service:** Implementierung als "Production Ready" Microservice mit JPA, Flyway, Resilience4j und Security.
-*   **Testing:** Stabilisierung der Test-Infrastruktur durch Entkopplung von Produktions- und Test-Konfigurationen (`TestPingServiceApplication`).
-*   **Docker:** Optimierung der Dockerfiles für Monorepo-Builds (BuildKit Cache Mounts, Layered Jars).
+*   **Delta-Sync API:** Implementierung von `/ping/sync` basierend auf Zeitstempeln.
+*   **Contract-Update:** Synchronisierung der API-Definitionen zwischen Backend und Frontend (`:contracts:ping-api`).
+*   **Testing:** Vollständige Testabdeckung für die neuen Sync-Endpunkte.
 
 ---
 
 ## 2. Technische Details
 
-### A. Gateway (`backend/infrastructure/gateway`)
-*   **Technologie:** Spring Boot 3.5.9 (WebFlux), Spring Cloud 2025.0.1.
-*   **Security:**
-    *   Fungiert als OAuth2 Resource Server.
-    *   Validiert JWTs von Keycloak (lokal oder Docker).
-    *   Konvertiert Keycloak-Rollen in Spring Security Authorities.
-*   **Routing:**
-    *   Routen sind typsicher in `GatewayConfig.kt` definiert (kein YAML mehr für Routen).
-    *   Circuit Breaker (`Resilience4j`) ist für Downstream-Services aktiviert.
-*   **Resilience:**
-    *   Fallback-Mechanismen für fehlende Services.
-    *   Health-Probes (`/actuator/health/liveness`, `/readiness`) aktiviert.
+### A. Sync-Strategie
+*   **Mechanismus:** Zeitstempel-basierter Delta-Sync.
+*   **API:** `GET /ping/sync?lastSyncTimestamp={epochMillis}`
+*   **Response:** Liste von `PingEvent` (ID, Message, LastModified).
+*   **Vorteil:** Clients laden nur geänderte Daten, was Bandbreite spart und Offline-Fähigkeit unterstützt.
 
-### B. Ping Service (`backend/services/ping/ping-service`)
-*   **Technologie:** Spring Boot 3.5.9 (MVC), Spring Data JPA.
-*   **Architektur:** Hexagonale Architektur (Domain, Application, Infrastructure).
-*   **Persistence:**
-    *   PostgreSQL als Datenbank.
-    *   Flyway für Schema-Migrationen (`V1__init_ping.sql`).
-*   **Security:**
-    *   Eigene Security-Konfiguration entfernt zugunsten der globalen `GlobalSecurityConfig` aus `backend:infrastructure:security`.
-    *   Endpunkte `/ping/secure` erfordern Authentifizierung.
-*   **Testing:**
-    *   `@WebMvcTest` stabilisiert durch `TestPingServiceApplication` (verhindert Laden von echten Services/Repos).
-    *   `@MockBean` (bzw. MockK) Strategie für UseCases und Repositories verfeinert.
+### B. Implementierung
+*   **Domain:** Erweiterung des `PingUseCase` um `getPingsSince(timestamp: Long)`.
+*   **Persistence:** Effiziente JPA-Query `findByCreatedAtAfter` auf dem `timestamp`-Index.
+*   **Security:** Der Sync-Endpunkt ist aktuell `public` (analog zu anderen Ping-Endpunkten), kann aber bei Bedarf geschützt werden.
 
-### C. Infrastruktur
-*   **Docker Compose:**
-    *   Services: Consul, Keycloak, Postgres, Redis.
-    *   Gateway und Ping-Service können lokal (Gradle) gegen die Docker-Infrastruktur laufen.
-*   **Dockerfiles:**
-    *   Optimiert für Monorepo (Dummy-Ordner für Frontend-Module, um Gradle-Config-Phase zu überstehen).
-    *   Multi-Stage Builds für minimale Image-Größe.
+### C. Frontend-Kompatibilität
+*   Die Frontend-Clients (`PingApiClient`, `PingApiKoinClient`) wurden aktualisiert, um den neuen Endpunkt zu unterstützen.
+*   Test-Doubles im Frontend wurden angepasst, um die Build-Integrität zu wahren.
 
 ---
 
 ## 3. Offene Punkte & Nächste Schritte
 
-*   **Frontend Integration (Phase 2):** Das Backend ist bereit für die Anbindung durch den Frontend-Experten.
-*   **Zipkin:** Tracing ist konfiguriert, aber Zipkin läuft noch nicht im Docker-Compose (optional für Phase 2).
-*   **Observability:** Prometheus-Metriken werden exponiert, Grafana-Dashboards müssen noch finalisiert werden.
+*   **Frontend Integration:** Der Frontend-Expert muss nun die Logik implementieren, um den `lastSyncTimestamp` lokal zu speichern und den Sync-Prozess zu steuern.
+*   **Konfliktlösung:** Aktuell ist der Sync unidirektional (Server -> Client). Für bidirektionalen Sync (Client -> Server) müssen noch Strategien (z.B. "Last Write Wins") definiert werden.
 
 ---
 
 ## 4. Fazit
-Das Fundament steht. Der "Tracer Bullet" hat den Weg durch das Backend erfolgreich durchquert. Wir haben eine stabile Basis für die Implementierung der Fachlichkeit.
+Das Backend ist bereit für Offline-First-Szenarien. Die Delta-Sync-Schnittstelle ist performant und einfach zu konsumieren.