Drucker wird in der App gewaehlt, nicht auf dem Pi

Das Einrichtungsskript fragte bisher am Pi, welcher Drucker bedient werden
soll. Damit stand die Einstellung an einem Ort, an den man nur mit einem
Terminal kommt - und ein zweiter Drucker am Pi bedeutete: Skript nochmal.

Jetzt fragt die App den Pi, was angeschlossen ist, und der Bediener waehlt in
den Einstellungen. Die Bruecke bekam dafuer /devices; sie liest die
Klartextnamen aus dem sysfs, damit dort "EPSON TM-T88IV" steht und nicht
"lp0" - bei zwei Druckern der Unterschied zwischen Wissen und Raten.

Der gewaehlte Pfad geht bei jedem Auftrag im Kopf X-Print-Device mit. Die
Bruecke haelt dazu bewusst keinen Zustand und das Skript schreibt kein
PRINT_DEVICE mehr: es soll genau eine Stelle geben, die weiss, welcher Drucker
gemeint ist, naemlich die, an der es bedient wird. Leer bleibt "automatisch" -
das erste gefundene Geraet, zugleich der Rueckfall, wenn aus lp0 nach dem
Umstecken ein lp1 geworden ist.

Der Pfad kommt damit von aussen und wird an beiden Enden geprueft, in
PUT /api/settings und noch einmal in der Bruecke. Eine Schranke, die nur an
einem Ende steht, ist keine: ohne die Pruefung auf dem Pi liesse sich der
Dienst dazu bringen, in eine beliebige Datei zu schreiben.

Nebenbei: ein nicht bereiter Drucker meldete sich in der Oberflaeche als
"HTTP 503". Das verriet niemandem, dass nur ein Stecker lose ist. Die 503 der
Bruecke ist kein Protokollfehler, und ihr Rumpf sagt, was fehlt - der wird
jetzt ausgewertet.

Geprueft am echten Pi (Debian 13, TM-T88IV): Einrichtung ohne Rueckfrage,
Geraeteliste mit Namen, ausdrueckliche Wahl, Druck darauf, Rueckkehr auf
automatisch, Druck darauf. Dazu die Abweise: /etc/passwd und ein Pfad mit
angehaengtem Befehl werden zurueckgewiesen, ein erlaubtes aber fehlendes
/dev/usb/lp7 ergibt eine Meldung im Klartext.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

DEPLOY.md

@@ -211,6 +211,7 @@ Passwort fehlen — lieber laut scheitern als unsicher laufen.
 | `PRINTER_PORT` | `9100` | Port der Brücke auf dem Pi |
 | `PRINTER_TOKEN` | leer | muss mit `PRINT_TOKEN` in `/etc/bondrucker/env` übereinstimmen |
 | `PRINTER_WIDTH` | `42` | Zeichen je Zeile: `42` bei 80-mm-Papier, `32` bei 58 mm |
+| `PRINTER_DEVICE` | leer | Gerät am Pi, z. B. `/dev/usb/lp0`. Leer = erstes gefundenes. Wird über die Oberfläche gepflegt |
 | `PRINTER_TIMEOUT_MS` | `6000` | Abbruch, wenn der Pi nicht antwortet |
 | `PUBLIC_URL` | leer | Adresse, unter der der Pi die App erreicht. Leer = aus der Anfrage abgeleitet (siehe Abschnitt 6) |
 
@@ -328,11 +329,33 @@ curl -fsSL "http://<timer-app>/setup/bondrucker.sh?code=…" -o bondrucker.sh
 sudo bash bondrucker.sh
 ```
 
-Das Skript prüft Python/systemd, **fragt, welcher Drucker verwendet werden
-soll** (mit Klartextnamen aus dem sysfs, also „EPSON TM-T88IV" statt „lp0"),
-legt Dienstbenutzer, Programm, udev-Regel und systemd-Unit an, erzeugt ein
-Token und meldet sich damit selbst bei der App an. Die Oberfläche pollt
-`/api/printer/setup-status` und springt um, sobald der Pi sich gemeldet hat.
+Das Skript prüft Python/systemd, legt Dienstbenutzer, Programm, udev-Regel und
+systemd-Unit an, erzeugt ein Token und meldet sich damit selbst bei der App an.
+Es läuft ohne Rückfrage durch. Die Oberfläche pollt `/api/printer/setup-status`
+und springt um, sobald der Pi sich gemeldet hat.
+
+#### Welcher Drucker bedient wird
+
+Das entscheidet die **App**, nicht der Pi. `GET /api/printer/devices` reicht die
+Frage an die Brücke weiter, die alle `/dev/usb/lp*` mit Klartextnamen aus dem
+sysfs zurückgibt („EPSON TM-T88IV" statt „lp0" — bei zwei Druckern der
+Unterschied zwischen Wissen und Raten). Die Auswahl landet in der Einstellung
+`printer_device` und geht bei **jedem** Auftrag im Kopf `X-Print-Device` mit.
+
+Die Brücke hält dazu keinen Zustand: es gibt genau eine Stelle, die weiß,
+welcher Drucker gemeint ist, und das ist die, an der es bedient wird. Ein
+`PRINT_DEVICE` in `/etc/bondrucker/env` schreibt das Einrichtungsskript
+deshalb nicht mehr.
+
+Leer heißt „automatisch": die Brücke nimmt das erste vorhandene `/dev/usb/lp*`.
+Das ist auch der Rückfall, wenn nach dem Aus- und Einstecken aus `lp0` ein
+`lp1` geworden ist.
+
+Der Pfad kommt damit von außen und wird an **beiden** Enden gegen
+`^/dev/(usb/)?lp[0-9]{1,3}$` geprüft — in `PUT /api/settings` und noch einmal in
+der Brücke. Eine Schranke, die nur an einem Ende steht, ist keine: ohne die
+Prüfung auf dem Pi ließe sich der Dienst dazu bringen, in eine beliebige Datei
+zu schreiben.
 
 **Warum der Pi sich meldet und nicht umgekehrt.** Vorher richtete die App den
 Pi per SSH ein. Das verlangte ein SSH-Passwort in einem Webformular, eine
@@ -505,8 +528,9 @@ Alle Endpunkte außer `/health`, `/api/login`, `/api/auth/status` und
 | `POST` | `/api/timers/:id/receipt` | Zwischenbon drucken, Timer bleibt unangetastet |
 | `DELETE` | `/api/timers/:id` | verwerfen, **nichts** speichern |
 | `GET` | `/api/settings` | Tarif, Bon-Texte und Druckerzustand lesen |
-| `PUT` | `/api/settings` | `{rateAmount, rateInterval}` sowie optional `{receiptHeader, receiptFooter, printAutoOnStop, receiptBarcodeEnabled, receiptBarcodeArticle}` |
+| `PUT` | `/api/settings` | `{rateAmount, rateInterval}` sowie optional `{receiptHeader, receiptFooter, printAutoOnStop, receiptBarcodeEnabled, receiptBarcodeArticle, printerDevice}` |
 | `GET` | `/api/printer/status` | Erreichbarkeit und Zustand des Druckers |
+| `GET` | `/api/printer/devices` | welche Drucker am Pi hängen, mit Klartextnamen |
 | `POST` | `/api/printer/test` | Probedruck |
 | `POST` | `/api/printer/setup-code` | erzeugt einen Einrichtungscode, liefert Abhol-Link und fertigen Befehl |
 | `GET` | `/api/printer/setup-status` | hat sich schon ein Pi gemeldet? |