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>

README.md

@@ -272,7 +272,7 @@ zu starten.
 | `SCANNER_ENCRYPTION_KEY` | eigener Schluessel fuer die Portal-Passwoerter; ohne ihn wird ein bekannter Ersatzschluessel benutzt und beim Start gewarnt |
 | `SCANNER_UPLOAD_DIR` | eigenes CV-Verzeichnis; leer = `<server>/uploads` |
 | `SCANNER_SCHEDULER` | Hintergrund-Scraper; Standard an, nur `false` schaltet ab |
-| `SCANNER_SCHEDULER_OFFSET` | Minuten Versatz fuer den ersten Lauf, Standard `30` |
+| `SCANNER_SCHEDULER_OFFSET` | Minuten Versatz fuer den **allerersten** Lauf, Standard `30`. Danach traegt `settings.last_scan_at` den Zeitplan ueber Neustarts hinweg |
 
 > **Kosten:** Beide Instanzen bewerten dieselben Projekte unabhaengig
 > voneinander - die OpenAI-Kosten fallen also doppelt an, solange die alte App
@@ -281,11 +281,15 @@ zu starten.
 > dann weiter.
 
 Der **Zeitversatz** ist nicht Kosmetik: beide Instanzen benutzen dieselben
-Portal-Sessions (aus derselben Cookie-Quelle) und wuerden nach einem Neustart
+Portal-Sessions (aus derselben Cookie-Quelle) und wuerden beim ersten Start
 gleichzeitig losziehen - das provoziert Rate-Limits und CAPTCHAs bei
 Freelancermap und Freelance.de. `SCANNER_SCHEDULER_OFFSET=30` verschiebt den
 ersten Lauf um 30 Minuten, danach laufen beide im eigenen Intervall verschraenkt.
-Wird der Wert >= Suchintervall gesetzt, wird er ignoriert.
+
+Ab dem zweiten Start traegt `settings.last_scan_at` den Zeitplan - die Frist
+greift dann nicht mehr. Sonst begann sie bei jedem Deployment von vorn und ein
+faelliger Lauf konnte beliebig lange ausfallen (siehe
+[docs/03-scanner.md](docs/03-scanner.md#wann-laeuft-er)).
 
 Innerhalb dieser Instanz kann **nur ein Lauf** gleichzeitig arbeiten: Scheduler
 und *Jetzt scannen* teilen sich eine Sperre (`isPipelineRunning`), ein zweiter