docs: backlog the encryption-key default and its missing documentation

Fallout from encrypting the LDAP bind password: the base compose file still
carries a hardcoded fallback key, so an install that never sets the variable
starts anyway and encrypts everything with a value that is in the repository.
The prod compose already requires it, which is the behaviour the base file
should have too.

Whether the example env files explain the key could not be checked in that
session, so the item says to look first rather than asserting it is missing.

Also notes, as an optional follow-up, why the variable is called
CALENDAR_ENCRYPTION_KEY and what a rename would have to handle.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

.planning/todos/pending/2026-08-11-verschluesselungsschluessel-vorgabewert.md

@@ -0,0 +1,63 @@
+---
+created: 2026-08-11
+title: Verschluesselungsschluessel — fest eingebauter Vorgabewert in der Basis-Compose, Dokumentation in der Beispiel-Umgebung fehlt vermutlich
+area: infra
+severity: minor
+trigger: vor der ersten Installation bei einem externen Kunden; intern folgenlos, solange die Variable gesetzt ist
+files:
+  - docker-compose.yml:46
+  - docker-compose.prod.yml:44
+  - .env.example
+  - .env.prod.example
+---
+
+## Problem
+
+Seit 4f687ea sind alle Zugangsdaten in der Datenbank verschluesselt — Kalender,
+SMTP, DKV-Postfach, Ausschreibungs-Postfach und nun auch das LDAP-Bind-Passwort.
+Der Schluessel dafuer kommt aus der Umgebungsvariable `CALENDAR_ENCRYPTION_KEY`
+und liegt bewusst NICHT in der Datenbank.
+
+Zwei Luecken drumherum:
+
+**1. Vorgabewert in der Basis-Compose.** `docker-compose.yml:46` lautet
+
+```
+CALENDAR_ENCRYPTION_KEY: ${CALENDAR_ENCRYPTION_KEY:-5dbbaba2...}
+```
+
+Ist die Variable nicht gesetzt, startet die Anwendung also trotzdem — mit einem
+Schluessel, der im Repository steht und damit jedem bekannt ist, der den Code
+hat. Die Verschluesselung sieht dann vorhanden aus, traegt aber nicht. Ein
+stiller Fehlstart ist hier schlechter als ein lauter: `docker-compose.prod.yml:44`
+macht es bereits richtig und verlangt die Variable ohne Vorgabe.
+
+**2. Dokumentation.** Ob `.env.example` / `.env.prod.example` den Schluessel
+erklaeren, konnte ich am 2026-08-11 nicht pruefen (Dateizugriff in der Sitzung
+blockiert) — beim Umsetzen also zuerst nachsehen. Falls er dort fehlt oder ohne
+Erklaerung steht, weiss bei einer Neuinstallation niemand, dass ein eigener
+Wert erzeugt werden muss und was passiert, wenn er spaeter verloren geht.
+
+Aufgefallen am 2026-08-11, als der User fragte, wo der Schluessel liegt und ob
+man ihn exportieren kann.
+
+## Solution
+
+1. Den Vorgabewert aus `docker-compose.yml:46` entfernen, sodass ein Start ohne
+   gesetzten Schluessel scheitert statt still einen bekannten zu verwenden.
+   Vorher pruefen, was das fuer die lokale Entwicklung heisst — moeglicherweise
+   braucht `docker-compose.dev.yml` dann einen eigenen, klar als Wegwerf-Wert
+   gekennzeichneten Eintrag, damit ein frisch geklontes Repo weiterhin
+   hochfaehrt.
+2. In beiden Beispiel-Umgebungsdateien den Schluessel dokumentieren: wie er
+   erzeugt wird (`openssl rand -hex 32`), dass er zu jedem Datenbank-Backup
+   gehoert und getrennt davon aufbewahrt werden sollte, und dass ein verlorener
+   Schluessel bedeutet, dass alle gespeicherten Zugangsdaten neu eingetragen
+   werden muessen.
+
+Optional im selben Zug, weil es beim Lesen sonst jedes Mal irritiert: der Name
+`CALENDAR_ENCRYPTION_KEY` stammt daher, dass das Kalender-Modul die
+Verschluesselung zuerst brauchte. Er gilt laengst fuer alle Zugangsdaten der
+Plattform. Eine Umbenennung muesste den alten Namen als Rueckfallebene lesen,
+sonst faellt jede bestehende Installation beim naechsten Start auf die Nase —
+siehe auch die Notiz dazu im LdapModule.