fix: Untis-Hub-Status ueber Geraete hinweg synchronisieren

UntisHubJobState (Faelligkeits-Zeitstempel des Untis-Hubs) lief bisher
ausserhalb des Sync - jedes Geraet fuehrte seine eigene Buchhaltung, wodurch
auf allen Instanzen dieselben Punkte offen blieben und ein bereits erledigter
Abgleich anderswo erneut WebUntis-Traffic ausgeloest haette (Nutzer-Feedback).

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

TODO.md

@@ -2097,6 +2097,26 @@ vollständig enthält.
     Zeilen), damit ein KI-Client für eine dort gelistete Gruppe nicht zusätzlich `get_groups`
     aufrufen muss, nur um den Fehlzeitenabgleich für sie auszulösen.
 
+  **Nachtrag (Nutzer-Feedback, 2026-09-13):** `UntisHubJobState` (die Fälligkeits-Zeitstempel
+  hinter dem Hub) lief bislang außerhalb des Sync — jedes Gerät führte seine eigene Buchhaltung.
+  In der Praxis zeigte das auf allen Instanzen dieselben offenen Punkte, was dem Zweck des Hubs
+  widerspricht (möglichst wenig WebUntis-Traffic: ein bereits auf Gerät A erledigter Abgleich soll
+  auf Gerät B nicht erneut als fällig erscheinen und zu einem zweiten, unnötigen Abruf verleiten).
+  Anders als die drei bewusst unsynchronisierten Report-Caches (`UntisAbsenceCacheRepository` &
+  Co., siehe oben) enthält `UntisHubJobState` keine WebUntis-Rohdaten, sondern nur Zeitstempel +
+  Kurztext — unkritisch für Sync.
+  - `UntisHubJobStateRepository.Save` ruft jetzt `db.OnChange` wie die übrigen ~28 synchronisierten
+    Repositories auf; `EventApplier` bekommt dafür einen zusätzlichen `Simple<UntisHubJobState>`-
+    Eintrag. Kein `Delete` nötig (Interface kennt keins) — Zeilen werden nur überschrieben.
+  - Geräte-Pairing (`SnapshotService`) war bereits unberührt, da es die komplette DB-Datei kopiert.
+  - Race-Härtung: `UntisHubService.RecordRun` legt bei einem (Kind, GroupId), das lokal noch nie
+    lief, eine neue `Id` an; laufen zwei Geräte offline denselben, noch nie ausgeführten Job
+    unabhängig voneinander, entstehen dadurch kurzzeitig zwei Datensätze für dasselbe Paar (kein
+    Unique-Index darauf). `UntisHubService.BuildRows` wählt deshalb jetzt den Datensatz mit dem
+    jüngsten `LastRunAt` statt eines beliebigen — der verwaiste zweite Datensatz bleibt harmlos in
+    der DB stehen (gleiches akzeptiertes v1-Verhalten wie bei anderen Entitäten ohne serverseitige
+    Merge-Logik, siehe TODO 10.3).
+
 ### 4.4 Wochen-/Tagesansicht
 - [x] **4.4.1** Kalenderansicht über alle Gruppen: Woche und Tag — siehe Nachtrag zu 4.3
       ("Heute"-Tab: Tagesliste unten angedockt, gruppenübergreifendes Wochenraster darüber, inkl.