feat(calendar): Termin einem Kalender zuordnen und umhaengen

Beim Anlegen war die Kalenderauswahl schon da (der oberste ist die
Vorgabe), beim Bearbeiten war sie festgestellt -- mit der Begruendung,
ein Umhaengen sei Loeschen und Neuanlegen unter neuer Kennung. Das
stimmt so nicht: In CalDAV wechselt dabei nur die Sammlung, UID und
Inhalt bleiben. Genau das macht der neue Endpunkt

    POST /api/v1/calendars/{id}/events/{uid}/move  {"calendar_id": …}

Er aendert nur die Zugehoerigkeit der Zeile und erhoeht das ctag auf
**beiden** Seiten. Mit nur einem holte ein Client die andere Haelfte
erst beim naechsten Vollabgleich, und der Termin stuende
zwischenzeitlich doppelt oder gar nicht im Telefon.

Bewusst ein eigener Endpunkt und kein weiteres Feld im PATCH: Ein Umzug
laesst sich auch ohne jede Aenderung am Termin ausloesen, und dafuer den
ganzen Termin mitschicken zu muessen waere eine Einladung, nebenbei
etwas zu ueberschreiben. Im Formular laeuft deshalb erst das PATCH und
dann der Umzug -- andersherum stuende der Termin nach einem Fehler
verschoben, aber unveraendert da, die verwirrendere Haelfte.

Dazu die Zieh-Geste: einen Termin auf einen Kalender in der
Seitenleiste ziehen, am Handy nach kurzem Gedrueckthalten. Ueber
Pointer-Events statt ueber die Drag-and-Drop-Schnittstelle des
Browsers -- die gibt es auf Android nicht, und genau dort soll die
Geste ja auch funktionieren. Ist die Kalenderliste zugeklappt (am Handy
der Regelfall), erscheint waehrend des Ziehens eine Leiste unten in
Daumennaehe, sonst liefe die Geste ins Leere.

Zwei Faelle, die sonst aergern: Wer in einen ausgeblendeten Kalender
zieht, bekommt ihn eingeblendet -- der Termin waere sonst scheinbar
spurlos verschwunden. Und der Klick, der einem Ziehen hinterherkommt,
wird verschluckt, statt den Termindialog zu oeffnen.

Eine Reihe zieht vollstaendig um; sie ist eine einzige Datei, kein
Buendel von Einzelterminen. Das sagt das Formular auch an.

Selbsttest um elf Pruefungen erweitert (36 gruen): Umzug angenommen,
Kennung bleibt, aus der Quelle weg und im Ziel da, ctag auf beiden
Seiten gestiegen, Umzug auf sich selbst folgenlos, fremder Kalender
404, Reihe vollstaendig umgezogen.

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

TESTING.md

@@ -17,14 +17,19 @@ einmal etwas schiefging:
 
     python3 scripts/kalender-selbsttest.py
 
-19 Prüfungen: Ganztags-Datum (der 3. muss der 3. bleiben – der Fehler, bei dem
+36 Prüfungen: Ganztags-Datum (der 3. muss der 3. bleiben – der Fehler, bei dem
 ein Termin östlich von UTC einen Tag zurücksprang), mehrtägige Termine,
 Terminfarbe in beiden Schreibweisen, alle Wiederholungsmuster (wöchentlich an
 bestimmten Tagen, monatlich/jährlich am festen Tag bzw. am n-ten Wochentag),
-Bearbeiten einer Reihe, und dass das Zeitfenster wirklich begrenzt.
+Bearbeiten einer Reihe, einen einzelnen Termin aus einer Reihe streichen
+(EXDATE), Umhängen in einen anderen Kalender (samt ctag auf **beiden** Seiten,
+sonst gleicht ein CalDAV-Client nur eine davon ab), und dass das Zeitfenster
+wirklich begrenzt.
 
 **Legt Termine an und löscht am Ende alle Termine im ersten Kalender des
-Kontos.** Also nur gegen eine Entwicklungsinstanz laufen lassen.
+Kontos**; für den Umzugstest entsteht kurzzeitig ein zweiter Kalender
+„T zweitkalender", der danach wieder verschwindet. Also nur gegen eine
+Entwicklungsinstanz laufen lassen.
 
 ## Notfall: Migration hängt fest ("Dirty database version")