test(calendar): CalDAV-Selbsttest, und fremde Benutzerpfade sauber abweisen

Der bisherige Selbsttest prueft die JSON-Schnittstelle, also den Weg der
Weboberflaeche. Der CalDAV-Weg -- der, den DAVx5 und Thunderbird gehen --
war nie automatisch geprueft, obwohl er ueber voellig anderen Code
laeuft. Ein gruener Lauf des einen sagt nichts ueber den anderen.

scripts/caldav-selbsttest.py geht ihn jetzt ab: Anmeldung (auch die
Regel, dass das Kontopasswort hier nicht gilt), Auffinden ueber
.well-known samt der Umleitung, der Clients mit GET folgen,
Kalenderliste, PUT/GET/DELETE, If-Match, calendar-query mit Zeitfenster,
calendar-multiget, beide Richtungen zwischen Web und CalDAV
(Ganztagsdatum mit exklusivem DTEND, Terminfarbe als CSS3-Name, RRULE,
EXDATE) und das Umhaengen aus Client-Sicht.

Dabei gefunden und behoben: Ein Pfad, der auf einen *anderen* Benutzer
zeigt, wurde mit einem leeren 207 beantwortet. Kein Datenleck -- die
Antwort ist leer, und der Backend nimmt den angemeldeten Benutzer, nicht
den aus dem Pfad. Aber der Client sieht dann einen Kalenderbestand ohne
Kalender und meldet "nichts gefunden" statt "falsche Adresse": die
stille Variante genau des Fehlers, der bei der Einrichtung schon einmal
Stunden gekostet hat. Jetzt 404. Bewusst nur ablehnen, was sicher fremd
ist; alles Unbekannte geht weiter an go-webdav.

Zwei Luecken bleiben und werden vom Skript als Hinweis gemeldet, weil
go-webdav v0.7.0 nur einen festen Satz Eigenschaften beantwortet und
keinen Haken bietet, eigene dazuzulegen: getctag fehlt (Clients listen
bei jedem Abgleich alles auf, statt billig nach Aenderungen zu fragen)
und calendar-color fehlt (der Kalender erscheint im Client in dessen
Vorgabefarbe -- Terminfarben sind nicht betroffen, die stehen im .ics).

39 Pruefungen gruen, JSON-Selbsttest weiter 36 gruen.

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

TESTING.md

@@ -31,6 +31,46 @@ Kontos**; für den Umzugstest entsteht kurzzeitig ein zweiter Kalender
 „T zweitkalender", der danach wieder verschwindet. Also nur gegen eine
 Entwicklungsinstanz laufen lassen.
 
+## CalDAV: Selbsttest per Skript
+
+Der Test oben prüft die JSON-Schnittstelle – also den Weg der
+Web-Oberfläche. Dieser hier geht den Weg eines echten Clients (DAVx5,
+Thunderbird, Apple Kalender). Beide führen auf dieselben Daten, aber über
+völlig verschiedenen Code: Ein grüner Lauf des einen sagt nichts über den
+anderen.
+
+    python3 scripts/caldav-selbsttest.py
+
+39 Prüfungen: Anmeldung (falsches Passwort und **Kontopasswort** werden
+abgewiesen – für CalDAV gelten nur App-Passwörter), Auffinden über
+`.well-known/caldav` samt der Umleitung, der Clients mit GET folgen,
+Kalenderliste mit Anzeigename und Komponenten, PUT/GET/DELETE eines
+Termins, `If-Match` (falsches ETag muss 412 geben), `calendar-query` mit
+Zeitfenster und `calendar-multiget`, beide Richtungen zwischen Web und
+CalDAV (Ganztagstermin als reines Datum mit exklusivem DTEND, Terminfarbe
+als CSS3-Name, RRULE, EXDATE), das Umhängen aus Client-Sicht (Datei
+verschwindet in der Quelle, taucht im Ziel auf, UID bleibt) und dass ein
+fremder Benutzerpfad 404 gibt statt eines leeren 207.
+
+Legt sich ein eigenes App-Passwort und zwei eigene Kalender an und räumt
+beides am Ende weg; vorhandene Kalender werden nur gelesen.
+
+### Zwei bekannte Lücken, die das Skript als Hinweis meldet
+
+Beide kommen daher, dass `go-webdav` v0.7.0 nur einen festen Satz
+Eigenschaften beantwortet und keinen Haken bietet, um eigene dazuzulegen:
+
+- ⚠️ **`getctag` fehlt** (Antwort 404). Clients können nicht billig fragen
+  „hat sich etwas geändert?" und listen stattdessen bei jedem Abgleich alle
+  Termine auf. Der Abgleich bleibt richtig, kostet aber mehr Daten und Akku.
+- ⚠️ **`calendar-color` fehlt** (Antwort 404). Der Kalender erscheint im
+  Client in dessen Vorgabefarbe. **Terminfarben** sind davon nicht
+  betroffen – die stehen im .ics selbst und kommen an.
+
+Dazu eine Ungenauigkeit ohne Folgen: Ein PUT, das einen vorhandenen Termin
+überschreibt, antwortet mit `201 Created` statt `204 No Content`. Das kommt
+ebenfalls aus go-webdav; Clients prüfen auf 2xx.
+
 ## Notfall: Migration hängt fest ("Dirty database version")
 
 Betrifft jede künftige Migration, nicht nur eine bestimmte. Nachgestellt und