feat(calendar): Abgleich nur der Aenderungen (sync-collection, RFC 6578)

Bis hierher holte jeder Durchgang die volle Terminliste: ctag abfragen,
Aenderung sehen, alles neu laden. Eine verschobene Besprechung kostete
damit so viel wie ein Neuanfang -- bei einem Jahr Termine, alle fuenfzehn
Minuten, auf Akku und Datenvolumen des Telefons.

Kein zweiter Zaehler: Das ctag **ist** bereits eine Zahl je Kalender, die
bei jedem Schreiben um eins steigt. Jedes Objekt merkt sich in sync_seq den
Stand, bei dem es zuletzt angefasst wurde (Migration 24).

Grabsteine (cal_tombstones) halten geloeschte UIDs fest -- ohne sie bliebe
ein geloeschter Termin auf jedem Geraet stehen, das gerade nicht verbunden
war. Sie stehen 180 Tage; beim Raeumen wandert sync_floor mit, und ein
Token darunter bekommt 403 <valid-sync-token/> statt einer Antwort mit
fehlenden Loeschungen.

go-webdav kennt fuer REPORT nur calendar-query und calendar-multiget, und
weder sync-token noch supported-report-set. Beide gehen denselben Weg wie
getctag und calendar-color. Ohne supported-report-set probiert DAVx5
sync-collection gar nicht erst aus.

Zwei Fehler noch vor dem Ausliefern gefunden:

* Die Anfuehrungszeichen am ETag standen **innerhalb** der Maskierung --
  xml.EscapeText machte daraus &#34;. Gueltig, aber genug Clients
  vergleichen ETags roh und saehen bei jedem Durchgang eine Aenderung.
* pruneTombstones nahm die erste Zeile eines DELETE ... RETURNING als
  Maximum. Das hat keine Reihenfolge -- der sync_floor waere zu niedrig
  gesetzt worden, und ein Client dazwischen haette Loeschungen verpasst.

caldav-selbsttest.py: 62 -> 86 Pruefungen.

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

backend/internal/calendar/model.go

@@ -27,9 +27,14 @@ type Calendar struct {
 	// PathSegment ist die Adresse, unter der ein Client diesen Kalender
 	// angelegt hat ("…/calendars/max/arbeit/"). Leer heißt: keine gewählte
 	// Adresse, es gilt die UUID. Siehe Ref.
-	PathSegment string    `json:"-"`
-	CTag        int64     `json:"ctag"`
-	CreatedAt   time.Time `json:"created_at"`
+	PathSegment string `json:"-"`
+	CTag        int64  `json:"ctag"`
+	// SyncFloor: Bis zu diesem Stand sind Grabsteine weggeräumt. Ein Token
+	// darunter lässt sich nicht mehr vollständig beantworten – der Client
+	// bekommt dann eine Absage und gleicht vollständig ab. Siehe
+	// Store.ChangesSince.
+	SyncFloor int64     `json:"-"`
+	CreatedAt time.Time `json:"created_at"`
 }
 
 // Ref ist das Pfadsegment, unter dem dieser Kalender in CalDAV erreichbar