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/02-datenmodell.md

@@ -168,12 +168,23 @@ Acht Eigenheiten, die man kennen muss:
   Zustand der Opportunity abgeleitet (Papierkorb oder weg), nicht gespeichert:
   wird sie zurückgeholt, verschwindet der Eintrag von selbst wieder. Die Regeln
   dafür stehen in `server/src/acquisitionRules.js`.
-  Aus derselben Logik folgt, was **Wiederherstellen** (`POST /:id/restore`) tut:
+  Aus derselben Logik folgt, was **Zurück in den Eingang** (`POST /:id/reopen`) tut:
   Es setzt `found_at` auf heute und leert `converted_at` samt `opportunity_id` -
   ohne das Zurücksetzen von `converted_at` bliebe ein Rückfaller im Archiv
   stehen, gleich welches Datum er trägt. Ein Kennzeichen
   „wiederhergestellt" gibt es nicht; es wäre der Zustand, den diese Tabelle
   gerade nicht führt.
+- **Der Papierkorb ist die Ausnahme davon.** Löschen von Hand ist eine
+  Entscheidung und kein Ablauf, deshalb steht sie in `deleted_at` (plus
+  `deleted_by`, ohne Fremdschlüssel - siehe `schema.sql`). Vorher war das
+  Löschen ein echtes `DELETE` und damit endgültig; jetzt bleibt die Zeile
+  90 Tage stehen. Was dort liegt, blenden **alle** anderen Abfragen aus
+  (`NOT_DELETED`): Eingang, Archiv, Menüzahlen und Dashboard.
+  Der Papierkorb rechnet ab `deleted_at`, nicht ab `found_at` - der
+  Aufräumlauf über das Funddatum lässt gelöschte Zeilen deshalb ausdrücklich
+  liegen, sonst wäre ein alter Fund im Papierkorb sofort weg.
+  `POST /:id/restore` räumt nur `deleted_at`/`deleted_by` weg und lässt das
+  Funddatum in Ruhe: der Eintrag soll dort wieder auftauchen, wo er hingehört.
 
 ### Postfach crm@perinco.de