fix(scanner): Zeitplan uebersteht Neustarts

Die Sperrfrist nach dem Start begann bei jedem Neustart von vorn. Zwei
Deployments im Abstand von zehn Minuten haben den faelligen Suchlauf damit
zweimal um eine halbe Stunde verschoben - er fand nie statt. Wer oefter als
alle SCANNER_SCHEDULER_OFFSET Minuten deployt, hat einen Scanner, der
automatisch nie sucht.

Der Zeitpunkt des letzten Laufs liegt jetzt in settings.last_scan_at, von der
Pipeline geschrieben (auch nach einem Abbruch, damit sich ein gescheiterter
Lauf nicht sofort wiederholt). Der Versatz greift nur noch, solange dort nichts
steht - also beim allerersten Start dieser Instanz, wo er gebraucht wird.

Der Scheduler liest den Wert zusaetzlich in jedem Tick: ein manueller Scan aus
der Oberflaeche schreibt ihn, weiss aber nichts von der Variablen im Scheduler.
Ohne den Abgleich konnte der Scheduler direkt hinter einem manuellen Lauf noch
einmal losziehen.

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

server/.env.example

@@ -52,9 +52,11 @@ SCANNER_UPLOAD_DIR=
 # dieselben Projekte unabhaengig voneinander - die OpenAI-Kosten fallen doppelt an.
 SCANNER_SCHEDULER=true
 
-# Minuten Versatz fuer den ersten Lauf nach einem Neustart. Verhindert, dass
+# Minuten Versatz fuer den allerersten Lauf dieser Instanz. Verhindert, dass
 # beide Scanner gleichzeitig mit denselben Portal-Sessions losziehen (CAPTCHA).
-# 0 = sofort loslegen. Wird ignoriert, wenn der Wert >= Suchintervall ist.
+# Greift nur, solange noch kein Lauf stattgefunden hat - danach traegt der in der
+# Datenbank gespeicherte Zeitpunkt (last_scan_at) den Zeitplan ueber Neustarts
+# hinweg. 0 = sofort loslegen.
 SCANNER_SCHEDULER_OFFSET=30
 
 # Fallback fuer den OpenAI-Key; bevorzugt wird der Wert aus den Einstellungen.