feat(station): Rettungsabbilder folgen dem Bildsatz-Umschalter beim Deploy

deploy.sh legt Rettungsabzuege jetzt in images/rescue-wlan/ (aus build/) und
images/rescue-nocreds/ (aus build-nocreds/) ab, statt sie flach in images/
abzulegen - dasselbe Muster wie migrate-wlan/migrate-nocreds, inklusive
derselben --delete-Vorsicht (nur bei vollstaendigem Satz). Alter flacher
Bestand wird bei jedem Deploy aufgeraeumt, auch bei einem gezielten.

README beschreibt den Umschalter jetzt fuer beide Betriebsarten.

tools/station/README.md

@@ -29,20 +29,21 @@ würde dort nur mit einer Fehlermeldung enden.
 ## Bildsatz: mit oder ohne WLAN-Zugangsdaten
 
 Die WLAN-Zugangsdaten stecken **zur Bauzeit** in der Firmware (`config.local.cmake`). Es
-gibt deshalb zwei Abzüge je Ziel, und die Station hält beide vor:
+gibt deshalb zwei Abzüge je Ziel, und die Station hält beide vor — **für beide
+Betriebsarten**, Migration **und Rettung**:
 
-| Umschalterstellung | Verzeichnis auf dem Pi | gebaut mit | die migrierte Lampe … |
-|---|---|---|---|
-| `ohne-wlan` (**Vorgabe**) | `images/migrate-nocreds/` | `tools/build_nocreds.sh` | startet im eigenen Onboarding-Zugangspunkt und wartet auf ein WLAN |
-| `mit-wlan` | `images/migrate-wlan/` | `build/` | hängt sofort im WLAN aus `config.local.cmake` |
+| Umschalterstellung | Migration | Rettung | gebaut mit | die Lampe … |
+|---|---|---|---|---|
+| `ohne-wlan` (**Vorgabe**) | `images/migrate-nocreds/` | `images/rescue-nocreds/` | `tools/build_nocreds.sh` | startet im eigenen Onboarding-Zugangspunkt und wartet auf ein WLAN |
+| `mit-wlan` | `images/migrate-wlan/` | `images/rescue-wlan/` | `build/` | hängt sofort im WLAN aus `config.local.cmake` |
 
 Umgeschaltet wird per `ninlight-station bildsatz ohne-wlan|mit-wlan` oder am Taster
-(Menüeintrag „Umschalten: …"). Das ist ein **Umschalter, keine Abfrage je Migration**: der
-Zustand steht in `/var/lib/ninlight-station/imageset`, überlebt Neustarts und bleibt, bis
-ihn jemand ändert. Genau deshalb steht er auch **dauerhaft in der Fußzeile des Panels** —
-in jedem Modus, auch bei ausgeschalteter Station: man soll vor jedem Einschalten sehen,
-was gilt, statt zwanzig Lampen mit den eigenen Zugangsdaten zu flashen, weil die
-Einstellung von vorletzter Woche noch stand.
+(Menüeintrag „Umschalten: …"). Das ist ein **Umschalter, keine Abfrage je Migration/
+Rettung**: der Zustand steht in `/var/lib/ninlight-station/imageset`, überlebt Neustarts
+und bleibt, bis ihn jemand ändert. Genau deshalb steht er auch **dauerhaft in der
+Fußzeile des Panels** — in jedem Modus, auch bei ausgeschalteter Station: man soll vor
+jedem Einschalten sehen, was gilt, statt zwanzig Lampen mit den eigenen Zugangsdaten zu
+flashen, weil die Einstellung von vorletzter Woche noch stand.
 
 **Warum `ohne-wlan` die Vorgabe ist** (und warum jeder Zweifelsfall — Datei fehlt,
 unlesbar, unbekannter Inhalt — dorthin führt): im Automatikmodus wird jede alte
@@ -51,14 +52,34 @@ ein Fehlgriff ärgerlich, aber harmlos — die Lampe steht im Onboarding-AP und
 dem Abzug mit Zugangsdaten steht das eigene WLAN-Passwort unwiderruflich in einem fremden
 Gerät. Der teurere Fehler darf nie der sein, der ohne Zutun passiert.
 
-**Fehlt der gewählte Satz** (nie ausgeliefert, oder `tools/build_nocreds.sh` nie gelaufen),
-wird **nichts** ausgeliefert — kein stilles Ausweichen auf den anderen Satz. Der Server
-antwortet mit 404 und `status: noimageset`, `ninlight-station status` sagt „FEHLT", und auf
-dem Panel steht „SATZ FEHLT". „Vorhanden" heißt dabei überall dasselbe: Verzeichnis da
-**und** mindestens ein Image darin.
+**Der Umschalter galt bisher nur für die Migration — jetzt auch für die Rettung, und das
+hat eine spürbare Folge.** Bis zu dieser Erweiterung bekam eine Rettung *immer* ein
+Abbild **mit** Zugangsdaten (der flache Bestand aus `build/`). Seitdem gilt für die
+Rettung dieselbe Vorgabe `ohne-wlan` wie für die Migration: **eine gerettete Lampe steht
+danach im eigenen Onboarding-Zugangspunkt statt im eigenen WLAN**, bis jemand ihr eines
+nennt. Das ist gewollt (dieselbe Abwägung wie oben — der teure Fehler darf nie der sein,
+der ohne Zutun passiert), soll aber niemanden überraschen: die Fußzeile des Panels zeigt
+den Bildsatz deshalb ausdrücklich auch im Rettungsmodus, und stellt man bewusst auf
+`mit-wlan` um, gilt das für beide Betriebsarten gemeinsam.
 
-`deploy.sh` liefert beide Sätze aus. Fehlt `build-nocreds/`, bleibt der Satz `ohne-wlan`
-auf dem Pi unangetastet (statt geleert zu werden) und der Lauf meldet, womit er entsteht.
+**Fehlt der gewählte Satz** (nie ausgeliefert, oder `tools/build_nocreds.sh` nie
+gelaufen), wird **nichts** ausgeliefert — kein stilles Ausweichen auf den anderen Satz,
+und auch nicht auf einen alten, flachen Bestand direkt in `images/` (siehe unten). Der
+Server antwortet mit 404 (Migration zusätzlich mit `status: noimageset`), und auf dem
+Panel steht „SATZ FEHLT" — in JEDEM Modus. „Vorhanden" heißt dabei überall dasselbe:
+Verzeichnis da **und** mindestens ein Image darin.
+
+`deploy.sh` liefert alle vier Sätze aus (migrate-wlan/migrate-nocreds für die Migration,
+rescue-wlan/rescue-nocreds für die Rettung). Fehlt `build-nocreds/` oder ist es für ein
+Ziel unvollständig, bleibt der jeweils betroffene Satz `ohne-wlan` auf dem Pi unangetastet
+(statt geleert zu werden) und der Lauf meldet, womit er entsteht.
+
+**Rückwärtskompatibilität bewusst nicht gegeben:** vor dieser Erweiterung lagen
+Rettungsabbilder flach in `images/` (immer mit Zugangsdaten). Ein Pi mit diesem alten
+Bestand muss **einmal neu per `deploy.sh` bestückt werden** — der Deploy räumt den
+flachen Altbestand dabei automatisch weg. Bis dahin liefert die Rettung in der Vorgabe
+`ohne-wlan` sichtbar nichts aus (statt den alten Bestand mit Zugangsdaten stillschweigend
+weiter zu bedienen, was den ganzen Sinn dieser Erweiterung unterlaufen würde).
 
 ## Taster am Gerät