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/src/scanner/services/pipeline.js

@@ -97,6 +97,15 @@ export const runMatchingPipeline = async () => {
     return await executePipeline();
   } finally {
     pipelineRunning = false;
+    /*
+     * Zeitpunkt festhalten, damit der Zeitplan einen Neustart uebersteht - sonst
+     * beginnt nach jedem Deployment die Wartezeit von vorn. Auch ein manueller
+     * Scan zaehlt: er hat die Boersen ja gerade abgefragt.
+     *
+     * Im finally, also auch nach einem Abbruch: ein gescheiterter Lauf soll sich
+     * nicht sofort wiederholen.
+     */
+    await Setting.setVal('last_scan_at', new Date().toISOString()).catch(() => {});
   }
 };