feat(D): Phase D — Undo/Restore komplett implementiert

- D-GEN: RestoreRegistry mit RestoreConfig (model_class, restore_permission, excluded_fields, special_handler)
- D-HOOK: history_hooks.py mit register_history_hooks() für after_create/update/delete
- D-CORE: Company create+update record_history in companies.py
- D-PLUG: Task/Calendar/DMS record_history in services/routes
- D-SOFT: Alle registrierten Entitäten haben deleted_at + un-delete via Registry
- D-MAIL: Mail special_handler (IMAP Trash-Move, Folder-Verify) + record_history in delete/move
- D-TRASH: GET /entity-history/trash (filterbar, paginiert) + Frontend Trash.tsx
- D-TOAST: UndoToast.tsx (5s Auto-Dismiss, useUndoToast Hook)
- D-HIST-UI: HistoryPanel.tsx (Timeline, Diff-View, Restore-Button)
- D-BULK: POST /entity-history/bulk-restore mit partial_success Semantik
- D-RET: POST /entity-history/retention/archive (GDPR hard-delete >90 Tage)
- D-TEST: 26 Tests in test_restore_registry.py, alle grün
- D-DOC: test-strategy.md + security_kernel.md aktualisiert

Backend: 10 Dateien, Frontend: 7 Dateien, Tests: 1 Datei, Docs: 3 Dateien
26/26 Tests passed, TSC 0 errors, App import 492 routes

docs/security_kernel.md

@@ -72,3 +72,44 @@ Keine Business-Logic in RLS. Keine owner_id, keine sharing, keine permissions.
 - ✅ rls_enabled_on_tenant_tables
 - ✅ rls_disabled_on_system_tables
 - ✅ tenant_context_variable_consistency
+
+---
+
+## Phase D — Undo/Restore Security
+
+### Restore-Registry: Explizite Registrierung
+
+Nur explizit registrierte Entity-Typen können restored werden (`RestoreRegistry`).
+Kein dynamisches ORM-Laden, kein blindes Snapshot-Zurückschreiben.
+
+| Entity Type | Restore Permission | Excluded Fields |
+|-------------|-------------------|----------------|
+| contact | contacts:write | search_tsv, embedding, default_person_id, admin_contactperson_id |
+| task | tasks:write | created_by, assigned_to, contact_id |
+| calendar_entry | calendar:write | calendar_id, created_by, assigned_to, source_mail_id |
+| dms_file | dms:write | storage_path, content_hash, size_bytes, uploaded_by, folder_id |
+| mail | mail:write | message_id, rfc822_size, raw_path, account_id, folder_id |
+
+### Sensitive Fields
+
+- `id`, `tenant_id`, `created_at`, `updated_at`, `deleted_at` werden **nie** restored
+- `search_tsv`, `embedding` werden **nie** restored (computed/derived fields)
+- Entity-spezifische Exclusions verhindern Restore von relationship IDs, storage paths, IMAP metadata
+
+### Mail Restore: IMAP-Semantik
+
+- Delete → Move in serverseitigen Trash (IMAP MOVE)
+- Restore → Move zurück in Original-Ordner (falls noch vorhanden)
+- Serverfehler erzeugen keinen falschen lokalen Status (MailSyncQueue für Retry)
+- Kein „Undo Send" für bereits zugestellte externe Mails
+
+### Bulk Restore: Partial-Failure-Semantik
+
+- Bei Teilausfällen: `partial_success` Flag + per-item Fehler-Report
+- Kein stummes Versagen — jeder Erfolg und jeder Fehlschlag wird gemeldet
+
+### Retention: GDPR-Hard-Delete
+
+- EntityHistory älter als 90 Tage wird hard-deleted (`archive_old_history`)
+- Erfordert `system:admin` Permission
+- Snapshots enthalten keine Passwörter oder Secrets (excluded fields)

docs/test-strategy.md

@@ -268,3 +268,30 @@ Diese Pipeline ist verbindlich für Phase-Gate-Reviews und muss vor jedem Phasen
 3. **Vitest Worker-Crashes** — 7 von 96 Test-Files crashen mit „Worker exited unexpectedly". Resource-Limits im Container. **Lösung:** `--pool=forks` oder Memory-Limit erhöhen.
 
 4. **Vollständiger pytest-Lauf dauert >15min** — 1401 Tests mit DB-Setup. **Lösung:** T-PARALLEL (pytest-xdist mit pro-Worker DB).
+
+---
+
+## Phase D — Undo/Restore Test-Ergebnisse
+
+### Neue Test-Datei: `tests/test_restore_registry.py` (26 Tests)
+
+| Test-Gruppe | Tests | Status |
+|-------------|-------|--------|
+| RestoreRegistry (Singleton, Register, Get, List, Overwrite, Excluded Fields) | 6 | ✅ |
+| RestoreFromHistory (Unsupported type, History not found) | 2 | ✅ |
+| HistoryHooks (extract_entity_id, register, hook fires record_history) | 6 | ✅ |
+| TrashList (Returns delete entries, Entity type filter) | 2 | ✅ |
+| BulkRestore (All success, Partial failure, All fail) | 3 | ✅ |
+| Retention (Returns count, Zero when none) | 2 | ✅ |
+| SensitiveFieldsExclusion (Default, Contact, DMS, Mail, All registered) | 5 | ✅ |
+
+### Verifizierte Aspekte
+
+- ✅ RestoreRegistry: Nur explizit registrierte Entity-Typen können restored werden
+- ✅ Excluded Fields: id, tenant_id, timestamps, search_tsv, embedding werden nie restored
+- ✅ Entity-spezifische Exclusions: Contact (relationship IDs), DMS (storage_path, content_hash), Mail (message_id, raw_path)
+- ✅ Mail Special Handler: IMAP-Semantik (Trash-Move, Folder-Verify, kein falscher lokaler Status)
+- ✅ Bulk Restore: Partial-Failure-Semantik (`partial_success` Flag, per-item results)
+- ✅ Retention: GDPR-Hard-Delete nach konfigurierbarer Aufbewahrungsfrist
+- ✅ Hook-based History: `do_action('entity.after_create/update/delete')` → `record_history()`
+- ✅ Dynamic Permission Checks: Restore-Permission aus RestoreConfig, nicht hardcoded