feat(personen): Personen und Self-Service Meine Schluessel (#013)

Personen lassen sich anlegen, bearbeiten und archivieren; ihr Detail
zeigt ihre Schluessel. Unter "Meine Schluessel" hinterlegt jede Rolle
eigene Public Keys (Freigabe Frage 4), wirksam erst nach Zuweisung
durch einen Operator oder Admin.

Warum so:
- Die eigene Person entsteht beim ersten Aufruf oder wird verknuepft:
  per benutzerId, sonst per E-Mail - aber nur, wenn der OIDC-Anbieter
  die Adresse bestaetigt hat. Dafuer merkt sich Benutzer jetzt
  emailBestaetigt (Migration); sonst koennte jemand mit selbst
  gewaehlter Adresse die Keys einer fremden Person sehen.
- Die Self-Service-Services nehmen nur den angemeldeten Benutzer und
  leiten die Person selbst ab; fremde Schluessel-IDs gelten als nicht
  vorhanden.
- Entfernen nur fuer eigene, selbst hinterlegte Keys ohne Verwendung,
  bedingt geloescht, damit eine gleichzeitige Zuweisung nicht per
  Cascade verschwindet.
- Archivieren statt Loeschen: wer bis wann welchen Key hatte, bleibt
  nachvollziehbar.

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

docs/issues/013-personen-selbstauskunft.md

@@ -1,20 +1,41 @@
 # #013 Personen und Self-Service
-**Status:** offen
+**Status:** erledigt
 **Meilenstein:** v0.2.0
 **Labels:** backend, ui
-**Geschätzt:** 2 h   **Tatsächlich:** –
+**Geschätzt:** 2 h   **Tatsächlich:** 0 h 10 min
 
 ## Ziel
 Personen verwalten; jeder angemeldete Benutzer kann eigene Public Keys hinterlegen, wirksam erst nach Zuweisung.
 
 ## Aufgaben
-- [ ] Personenliste/-detail
-- [ ] Seite „Meine Schlüssel“
+- [x] Personenliste/-detail
+- [x] Seite „Meine Schlüssel“
 
 ## Akzeptanzkriterien
-- [ ] Leser kann nur eigene Keys hinterlegen, nicht zuweisen
+- [x] Leser kann nur eigene Keys hinterlegen, nicht zuweisen
 
 ## Abhängigkeiten
 #012
 
 ## Notizen / Entscheidungen
+- **Personen pflegt, wer Schlüssel verwaltet** (Recht `schluesselVerwalten`, Admin und Operator) –
+  ein eigenes Recht wäre nur ein Alias. Lesen dürfen alle Rollen.
+- **Archivieren statt Löschen:** die Schlüssel bleiben der Person zugeordnet (wer hatte bis wann
+  welchen Key?), die Kontoverknüpfung entfällt, damit der Self-Service nicht bei einer
+  archivierten Person landet. Die Notiz steht nicht im Protokoll, nur dass sie sich änderte.
+- **Self-Service `/meine-schluessel`** (Recht `eigeneSchluesselHinterlegen`, alle Rollen,
+  Navigation „Meine Schlüssel“): beim ersten Aufruf wird die eigene Person angelegt oder
+  verknüpft – per `benutzerId`, sonst per E-Mail, aber **nur bei vom Anbieter bestätigter
+  Adresse** und genau einer freien, nicht archivierten Person. Dafür neue Spalte
+  `Benutzer.emailBestaetigt` (Migration `20261012103000_benutzer_email_bestaetigt`), gesetzt bei
+  jeder OIDC-Anmeldung. Ohne sie könnte jemand mit selbst gewählter Adresse die Keys einer fremden
+  Person sehen.
+- Hinterlegte Keys: Kategorie `PERSON`, `selbstHinterlegt = true`, Protokoll
+  `schluessel.selbst_hinterlegt`. Hinweis in der Oberfläche: „Wirksam erst, wenn ein Operator
+  oder Admin den Schlüssel einem Host zuweist.“
+- **Entfernen** nur eigene, selbst hinterlegte Keys ohne jede Verwendung (auch keine entfernte –
+  der Verlauf am Key bleibt). Das Löschen ist bedingt (`deleteMany` mit „keine Verwendungen“),
+  damit eine gleichzeitige Zuweisung nicht per Cascade verschwindet. Fremde IDs gelten als „nicht
+  vorhanden“. Tests: `tests/personen.test.ts`.
+- Die Services nehmen den angemeldeten Benutzer entgegen und leiten die Person selbst ab; die
+  Actions reichen keine `personId` von außen durch (struktureller Test).