fix: Sync blockierte dauerhaft und unsichtbar bei fehlerhaftem Ereignis

EventApplier.ApplyAsync fing bisher nur LiteException ab - jede andere
Ausnahme (z.B. eine fehlerhafte Entschlüsselung/Deserialisierung eines
einzelnen Ereignisses) fiel unbehandelt aus der Pull-Schleife in
SyncEngine.PullAsync heraus, bevor der Fortschritt (SetLastServerSeq)
gespeichert wurde. Der nächste Sync-Versuch lud denselben Batch erneut
und scheiterte am selben Ereignis wieder - ein dauerhaft blockierter
Sync, bei dem selbst bereits erfolgreich angewendete Ereignisse im
selben Batch nie als erledigt markiert wurden. Zusätzlich protokollierte
weder SyncEngine noch EventApplier irgendetwas, ein Fehlschlag zeigte
sich höchstens als knapper Text in der Sync-Statusleiste.

EventApplier fängt jetzt jede Ausnahme pro Ereignis ab (geloggt über
AppLogger, übersprungen statt den Batch zu blockieren); SyncEngine
loggt jeden Sync-Fehlschlag vollständig. Betrifft nur den Desktop-Client,
kein API-Redeploy nötig.

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

TODO.md

@@ -1514,6 +1514,36 @@ die Docker-Verifikation unter 10.2.4 (kein Docker im Entwicklungsstand verfügba
       Namens-Eindeutigkeit bei Aspekten u.ä.) werden auf diesem Pfad nicht geprüft — nur harte
       LiteDB-Unique-Constraints greifen noch und führen zum Überspringen des einzelnen Ereignisses.
       Für Einzel-/Wenig-Geräte-Nutzung akzeptiert, siehe 10.3.4.
+
+      **Nachtrag (Bugfix — blockierter Sync bei jedem Fehler, unsichtbar und ungeloggt):**
+      Nutzer-Bug-Report — nach erfolgreicher Gerätekopplung kam eine neu angelegte `Lesson` auf dem
+      zweiten Gerät trotz mehrfacher manueller Synchronisation nicht an. Ursache im Code gefunden
+      (nicht live reproduziert, da keine zwei physischen Testgeräte zur Verfügung stehen):
+      `EventApplier.ApplyAsync` fing bisher nur `LiteException` ab — jede andere Ausnahme (z.B.
+      eine fehlerhafte Entschlüsselung/Deserialisierung eines einzelnen Ereignisses) fiel
+      unbehandelt aus der `foreach`-Schleife in `SyncEngine.PullAsync` heraus, **bevor**
+      `_queue.SetLastServerSeq()` erreicht wurde. Der nächste Sync-Versuch lud dadurch denselben
+      Ereignis-Batch erneut und scheiterte am selben Ereignis erneut — ein dauerhaft blockierter
+      Pull, bei dem selbst bereits im selben Batch erfolgreich angewendete Ereignisse nie als
+      erledigt markiert wurden. Verschärft durch fehlende Sichtbarkeit: weder `SyncEngine` noch
+      `EventApplier` protokollierten Ausnahmen — ein Fehlschlag zeigte sich höchstens als knapper
+      "Fehler: …"-Text in der kleinen Sync-Statusleiste, ohne Log-Eintrag (derselbe blinde Fleck wie
+      beim Pairing-Bugfix in 10.3.1).
+
+      **Umsetzung:** `EventApplier.ApplyAsync` fängt jetzt jede Ausnahme pro Ereignis ab (protokolliert
+      über neu injizierten `AppLogger`, übersprüngen statt den ganzen Batch abzubrechen) — ein
+      einzelnes fehlerhaftes Ereignis kann den Sync nicht mehr dauerhaft blockieren. `SyncEngine`
+      loggt seinerseits jeden Sync-Fehlschlag (HTTP wie generisch) vollständig statt nur die
+      knappe `ex.Message` im Status anzuzeigen. Neuer Regressionstest
+      (`SyncEngineTests.SyncNowAsync_KorruptesEreignisImPullBatch_BlockiertNachfolgendeEreignisseNicht`)
+      belegt mit einem absichtlich korrupten Ereignis vor einem gültigen im selben Pull-Batch, dass
+      Zweiteres trotzdem ankommt und `GetLastServerSeq()` fortschreitet statt stecken zu bleiben.
+      **Wichtig:** betrifft nur `LehrerApp.Sync`/`LehrerApp.Desktop` — der Server (`LehrerApp.Api`)
+      ist unverändert, ein Redeploy der API ist für diesen Fix nicht nötig, wohl aber ein
+      Neu-Build/Neustart der Desktop-Clients. Ob dies tatsächlich die vom Nutzer beobachtete Ursache
+      war, ist damit noch nicht bestätigt — nach dem Update sollte ein erneuter Testlauf entweder
+      funktionieren oder jetzt einen konkreten, geloggten Fehler liefern statt eines stillen
+      Fehlschlags.
 - [x] **10.1.8** Datei-Anhänge (Dokumentation) über den laufenden Sync mitschicken.
 
       **Umsetzung:** Eigener, unverschlüsselt im JSON-Ereigniskanal nicht mitgeführter Binärkanal