fix: eigener Push ließ Client seinen Pull-Cursor über fremde Ereignisse springen

SyncEngine.PushAsync setzte den lokalen Pull-Cursor bisher aus PushResponse.ServerSequenceNr -
dem globalen Zähler über alle Geräte nach dem eigenen Push, nicht dem tatsächlich zugestellten
Stand. War beim Server zu diesem Zeitpunkt bereits ein noch nicht abgeholtes Ereignis eines
anderen Geräts mit niedrigerer ServerSeq vorhanden, sprang der Cursor darüber hinweg und der
direkt folgende Pull bekam 0 Ereignisse, ohne es je angewendet zu haben - ein zweiter,
unabhängiger Cursor-Bug mit demselben Symptom wie der vorherige Wasserzeichen-Fix, diesmal
client- statt serverseitig.

Ergänzt außerdem einen "Vollständigen Sync erzwingen"-Button in den Sync-Einstellungen, damit
bereits durch diesen Bug zu weit vorgerückte Geräte ihren Fortschritt manuell zurücksetzen und
alle Ereignisse erneut laden können.

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

TODO.md

@@ -1639,6 +1639,36 @@ die Docker-Verifikation unter 10.2.4 (kein Docker im Entwicklungsstand verfügba
         `AssignedServerSeqs`, `GetLatestForEntity`), `EventQueueTests`
         (`GetKnownServerSeq`/`SetKnownServerSeq`), `SyncEngineTests` (Dedup, frisch gesetztes
         `BasedOnServerSeq`, Versionsverfolgung nach Erfolg, RemoteWon- und LocalWon-Ablehnung).
+- [x] **10.1.10** Zweiter, unabhängiger Pull-Cursor-Bug (Nutzer-Bug-Report direkt nach dem
+      Deploy von 10.1.9): "Client 1 hat übermitteln können. Der 2. PC erhält immer noch die
+      Mitteilung, dass es keine Änderungen für ihn gibt."
+
+      **Ursache:** `SyncEngine.PushAsync` setzte den lokalen Pull-Cursor bisher direkt aus
+      `PushResponse.ServerSequenceNr` — das ist bei `EventStore.Push` der **globale** Zähler über
+      ALLE Geräte NACH diesem Push (`seq = LastSeq(col)`, dann je akzeptiertem Ereignis
+      hochgezählt), nicht der Stand, den DIESES Gerät tatsächlich per Pull erhalten hat. Hatte der
+      Server zum eigenen Push-Zeitpunkt bereits ein noch nicht abgeholtes Ereignis eines ANDEREN
+      Geräts mit niedrigerer ServerSeq, sprang der Cursor beim eigenen Push darüber hinweg — der
+      direkt anschließende `PullAsync` (läuft in `SyncNowAsync` immer sofort danach) fragte dann
+      schon mit einem zu hohen "since" und bekam 0 Ereignisse, obwohl das fremde Ereignis nie
+      angewendet wurde. Ein zweiter, unabhängiger Bug mit demselben Symptom wie die
+      Wasserzeichen-Korrektur zu 10.1.7 — diesmal nicht in `EventStore.Pull` selbst, sondern im
+      Client, der sich mit dem PUSH-Antwortwert seinen eigenen (fixen) Pull-Cursor kaputtmachte.
+
+      **Fix:** Die Zeile `_queue.SetLastServerSeq(result.ServerSequenceNr)` in `PushAsync`
+      ersatzlos entfernt — `PullAsync` pflegt den Cursor bereits korrekt selbst, ausschließlich
+      anhand tatsächlich zugestellter Ereignisse (siehe 10.1.7). Neuer Regressionstest
+      `SyncEngineTests.SyncNowAsync_EigenerPushWaehrendFremdesEreignisNochAussteht_
+      LiefertFremdesEreignisTrotzdem` reproduziert exakt dieses Szenario (eigener Push während ein
+      fremdes Ereignis mit niedrigerer ServerSeq noch aussteht) und schlägt ohne den Fix fehl.
+
+      **Reparatur bereits betroffener Geräte:** Da der Cursor ein reines Vorwärts-Wasserzeichen
+      ist, kann ein durch diesen Bug bereits zu weit vorgerückter lokaler Stand sich nicht von
+      selbst heilen — der Fix verhindert nur künftige Fälle. Neuer Button "Vollständigen Sync
+      erzwingen" im Settings-Tab „Synchronisation" (`SettingsViewModel.SyncForceFullResync`)
+      setzt `EventQueue.SetLastServerSeq(0)` und stößt danach `SyncEngine.SyncNowAsync()` an —
+      sicher wiederholbar, da `EventApplier` jedes Ereignis idempotent per Upsert/Delete-by-Id
+      anwendet.
 
 ### 10.2 Server
 - [x] **10.2.1** Benutzerverwaltung/Registrierung prüfen und absichern