feat(akquise): Papierkorb fuer geloeschte Eintraege

Loeschen in der Akquise war ein echtes DELETE: der Eintrag stand danach
in keiner Liste, auch nicht im Archiv, und war nicht zurueckholbar. Jetzt
setzt es `deleted_at`/`deleted_by`, die Zeile bleibt 90 Tage stehen.

Der Papierkorb ist die eine Ausnahme von der Regel, dass diese Tabelle
keinen Zustand fuehrt: Loeschen von Hand ist eine Entscheidung, kein
Ablauf. Was dort liegt, blenden alle anderen Abfragen ueber NOT_DELETED
aus - Eingang, Archiv, Menuezahlen und Dashboard. Der Aufraeumlauf ueber
`found_at` laesst geloeschte Zeilen ausdruecklich liegen, sonst waere ein
alter Fund im Papierkorb sofort weg; der Papierkorb raeumt ab
`deleted_at`.

Zwei Rueckwege, deshalb zwei Routen. `/reopen` (bisher `/restore`) holt
aus dem Archiv in den Eingang und setzt das Funddatum auf heute.
`/restore` holt aus dem Papierkorb zurueck und laesst das Funddatum in
Ruhe - der Eintrag soll dort auftauchen, wo er hingehoert, also im
Archiv, wenn er alt ist. Die Meldung nennt das Ziel.

Dazu `DELETE /:id/permanent` und `POST /trash/empty`. Im Papierkorb wird
nicht gepflegt: Bearbeiten und Uebernehmen antworten 409.

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

docs/05-frontend.md

@@ -13,7 +13,9 @@ flowchart TD
     K --> AQ["Akquise"]
     AQ --> AQ1["Eingang<br/>Funde der letzten 14 Tage"]
     AQ --> AQ2["Archiv<br/>älter; nach 90 Tagen gelöscht"]
-    AQ2 -. "Wiederherstellen<br/>(Funddatum = heute)" .-> AQ1
+    AQ --> AQ3["Papierkorb<br/>von Hand gelöscht; 90 Tage"]
+    AQ2 -. "Zurück in den Eingang<br/>(Funddatum = heute)" .-> AQ1
+    AQ3 -. "Wiederherstellen<br/>(Funddatum bleibt)" .-> AQ2
     K --> O["Opportunities"]
     K --> C["Interviews"]
     K --> L["Kontakte"]