Deploy-Anleitung + Cron-Endpoint stilllegen

Der Tarif hat jetzt SSH und Shell-Cronjobs. Damit fällt die Begründung für
public/cron.php weg: der Endpoint war ausschließlich der Ersatz dafür.
cron.key steht in der Produktiv-Config auf '' (403 auf jeden Aufruf), der Code
bleibt als Rückweg samt Begründung stehen.

docs/deploy.md beschreibt den Weg in kleinen Schritten. Kern: die neue Seite
läuft erst auf einer per Verzeichnisschutz geschlossenen Test-Subdomain mit
DERSELBEN Produktiv-Config, die später live geht — kein Config-Wechsel beim
Umschalten. Möglich, weil die Host-Weiterleitung in public/.htaccess nur beim
exakten Host ohne www greift. Die alte CMS-Seite bleibt bis zuletzt online und
ist der Rückweg.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NzeVVgMCrzCDJAKeLEdKr7

CLAUDE.md

@@ -7,7 +7,8 @@ selbst gehosteter Stack ohne Abhängigkeiten von Drittanbietern.
 
 - **Frontend:** Natives HTML, Vanilla CSS, Vanilla JS. Kein Framework, keine Build-Pipeline, kein Node.
 - **Backend:** Vanilla PHP ≥ 8.1, Composer nur für `phpmailer/phpmailer`. Keine Template-Engine.
-- **Hosting-Ziel:** Apache Shared Hosting, PHP 8.x, `.htaccess`, Cronjobs verfügbar.
+- **Hosting-Ziel:** All-Inkl Shared Hosting, PHP 8.x, `.htaccess`, SSH **und** Shell-Cronjobs
+  (seit 31.07.2026 im Tarif). Deploy-Anleitung Schritt für Schritt: **`docs/deploy.md`**.
 - **Lokales Dev:** `php -d upload_max_filesize=250M -d post_max_size=260M -S localhost:8000 -t public public/index.php`
   (index.php fungiert als Router-Script, weil `php -S` kein .htaccess kennt). Die beiden `-d`-Schalter
   brauchst du für die Dateiablage `/dateien`: der CLI-Server liest keine `.user.ini`, und mit den
@@ -329,11 +330,21 @@ Keine rohen Werte in `base/layout/components/utilities.css` — es gibt für all
 - [ ] Keine Duplikate: Inhalte/Werte aus den Single-Source-Dateien beziehen
 - [ ] `php -l` sauber; Seite lokal geprüft
 
-## Cron-Endpoint `public/cron.php` (Ausnahme 3b)
+## Cron-Endpoint `public/cron.php` (Ausnahme 3b) — **stillgelegt**
 
-**Der Tarif kennt keine zeitgesteuerten Aufgaben** — das KAS meldet „in deinem Tarif nicht verfügbar",
-weder Shell- noch URL-Cronjobs (geprüft 27.07.2026). Die Sync-Skripte müssen aber getaktet laufen, also
-kommt der Takt von außen: ein externer Cron-Dienst ruft
+**Seit 31.07.2026 hat der Tarif SSH und echte Shell-Cronjobs.** Damit ist der Endpoint überflüssig:
+er war ausschließlich der Ersatz für den fehlenden Cron. `cron.key` steht in der Produktiv-Config auf
+`''`, der Endpoint antwortet also auf jeden Aufruf mit 403 — ein Geheimnis weniger, das bei einem
+externen Dienst liegt und leaken kann. Der Takt läuft über die Crontab-Zeilen aus
+`config/config.example.php` (Weg A), der Ablauf steht in **`docs/deploy.md`**, Teil D.
+
+**Der Code bleibt.** Er ist geprüft, kostet nichts (403 in drei Zeilen) und ist der Rückweg, falls der
+Shell-Cron ausfällt: neuen Schlüssel in `cron.key`, fertig. Deshalb sind die Grenzen unten weiter
+beschrieben, statt sie mit dem Code zu löschen — wer ihn je wieder aufschließt, braucht sie.
+`bin/preflight.php` warnt bei leerem Schlüssel und weist damit auf genau diese Entscheidung hin;
+die Warnung ist erwartet, kein Mangel.
+
+Die Begründung von damals, weiterhin gültig für den Fall der Reaktivierung: ein externer Cron-Dienst ruft
 `https://…/cron.php?job=matchcenter` bzw. `?job=instagram` auf, der Endpoint startet das Skript
 serverseitig. Schlüssel aus `config('cron.key')`, per Header `X-Cron-Key` **oder** als `key`-Parameter.
 
@@ -363,8 +374,8 @@ Besucher keine Aktualisierung, und Fire-and-Forget ist auf Shared Hosting unzuve
 `$argv` wird im Endpoint gesetzt, weil es im Web-SAPI nicht existiert.
 
 `bin/preflight.php` prüft Schlüssellänge, Verwechslung mit `app_secret` und ob `min_interval` den
-gewünschten Takt sperrt. **Wenn der Tarif je Cronjobs bekommt:** `cron.key` leeren, dann ist der
-Endpoint zu, und der Takt läuft wieder wie in `config.example.php` dokumentiert.
+gewünschten Takt sperrt. Der damals hier notierte Ausstieg („wenn der Tarif je Cronjobs bekommt,
+`cron.key` leeren") ist am 31.07.2026 genau so eingetreten und vollzogen.
 
 **Offen:** ob der Instagram-Scraper von der Server-IP überhaupt durchkommt. Instagram sperrt
 Rechenzentren; hier lief er nur über einen privaten Anschluss. Einmal auf dem Server prüfen. Falls er