dev: Historie von den Produktiv-SQL-Dumps bereinigt, lokale Dateien mit Personenbezug gelöscht

- Zuordnung alter zu neuen Commit-Hashes in dev/archive/commit-map-2026-10-09.txt
- Git-Deploy-Protokoll: Eintrag und einmaliger Server-Abgleich (Tags mit
  --force holen, gc), Speicherbereinigung in Forgejo und auf dem NAS
- README und Roadmap 1.1/1.4 nachgeführt

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

dev/betrieb/git-deploy.md

@@ -266,3 +266,24 @@ Ausfall des Anbieters keinen Deploy abbricht.
 | 08.10.2026 | `v1.6.0` | Mit Migration (`users.sessions_revoked_at_ms`, Batch 22). Härtung aus Phase 4 des Sicherheitsaudits: „Andere Geräte abmelden“, IP-weites Login-Limit (20 Fehlversuche in 15 Minuten), dauerhafte Session-Sperrmarke, Passwörter ab 12 Zeichen mit Leak-Abgleich, CSP im Melde-Modus (`storage/logs/csp-*.log`), npm `shell-quote`/`source-map-js`. Nach dem Deploy: Header `content-security-policy-report-only` vorhanden, Umami- und GlitchTip-Host in `script-src`/`connect-src`. CSP-Log in einigen Tagen auswerten. |
 | 08.10.2026 | `v1.6.1` | Vorher auf dem Server `php8.4-imagick` installiert und FPM neu geladen: Die Erweiterung fehlte auf Live, Herkunftsprüfung und KI-Vorab-Check der Bilder liefen seitdem ins Leere. Release: Zeile „PHP-Erweiterung Imagick“ in der Betriebsüberwachung, gebaute Livewire-Anfragen von Scannern (GlitchTip 38, 39) als 400 statt 500/419, Browser-Filter für abgebrochene Alpine-Übergänge (GlitchTip 18). Keine Migration. Nach dem Deploy: Betriebsüberwachung „Imagick ist geladen“. |
 | 09.10.2026 | `v1.7.0` | Spamschutz für Kontakt-Widget und Registrierung (Cloudflare Turnstile, Inhaltsfilter mit Spam-Quarantäne, Namensregel bei der Registrierung). Bei nicht erreichbarem Cloudflare wird durchgelassen und markiert. Keine Migration. Vorher: Turnstile-Keys in der `.env`, Widget im Cloudflare-Dashboard mit allen drei Live-Hostnamen. Nach dem Deploy: Kontakt-Widget im Browser getestet, Betriebsüberwachung „Spamschutz (Cloudflare Turnstile)“ grün. `contact-messages:quarantine-spam`: 152 Anliegen in die Quarantäne, 130 offen (Rest per Sammelaktion), echte Korrekturanfragen blieben offen. `users:prune-bot-registrations` nach freigegebenem Probelauf ausgeführt, danach `USERS_PRUNE_BOT_REGISTRATIONS=true` und `config:cache`. |
+| 09.10.2026 | Historie bereinigt | Die Produktiv-SQL-Dumps vom 23.04. (`dev/migration 2026/sql`, ~290 MB, Kundendaten) lagen seit `5b8bdf4` in der Historie und auf beiden Remotes. Mit `git filter-branch` aus allen Branches und Tags entfernt; Dateibäume und Commitzahlen aller 21 Refs unverändert, **alle Hashes neu** (Zuordnung alt → neu: [`commit-map-2026-10-09.txt`](../archive/commit-map-2026-10-09.txt)). Tags `v1.0.0`–`v1.7.0` neu gesetzt, gleicher Inhalt. Force-Push auf `origin` und `NAS`, danach einmalig der Server-Abgleich unten. |
+
+### Einmalig nach der Historienbereinigung (09.10.2026)
+
+`deploy.sh` holt Tags ohne `--force` und würde an den neu gesetzten Tags
+scheitern („would clobber existing tag“). Auf dem Server einmal:
+
+```bash
+cd ~/pressekonto.com
+git status --porcelain              # muss leer sein
+git fetch --force --tags --prune origin
+git checkout --quiet --detach v1.7.0   # gleicher Inhalt, neuer Hash — keine Dateiänderung
+git reflog expire --expire=now --all && git gc --prune=now
+git count-objects -vH               # size-pack deutlich unter 300 MB
+```
+
+`RELEASE` bleibt `v1.7.0`, ein Deploy ist nicht nötig. Danach läuft
+`deploy.sh` wie gewohnt. Jeder andere Klon (weitere Rechner) wird neu geklont.
+In Forgejo und auf dem NAS die Speicherbereinigung des Repositorys anstoßen,
+sonst bleiben die alten Objekte dort bis zur nächsten automatischen
+Bereinigung liegen.