Wartung: Online-Watchdog nach Neustart, Status-Reset, Zugangsdaten-Spalte

- Nach einem ausgelösten SSH-Neustart blieb der Job-Status bisher für
  immer auf "Neustart ausgelöst" stehen -- ergänzt um einen Ping-
  Watchdog (gleiche Invocation wie das bestehende Monitoring in
  poe.sh: "ping -c 1 -W 2"), der nach einer kurzen Schonfrist (15s)
  regelmäßig prüft, bis das Gerät wieder antwortet (Timeout 5min).
  Status wechselt dann sichtbar auf "wieder online" bzw. auf einen
  Fehler bei Zeitüberschreitung.
- Ein abgeschlossener ERFOLGREICHER Job wird bei jedem (erneuten) Laden
  der Wartungsseite zurückgesetzt (wieder "Noch keine Aktion") -- ein
  Erfolg ist nur relevant, solange man ihn live mitverfolgt. Fehler
  bleiben bewusst bis zur nächsten Aktion sichtbar, um sie nicht durch
  einen einfachen Reload zu übersehen.
- Clients-Tabelle zeigt jetzt wie die Switche-Tabelle eine
  "Zugangsdaten"-Spalte (Name + Username oder "— keine —").

Live gegen das dedizierte Testsystem verifiziert: zwei echte Neustarts,
beide per uptime -s bestätigt (kein False-Positive-Ping gegen die noch
nicht heruntergefahrene alte Instanz), Status korrekt von "wartet auf
Online" auf "wieder online" gewechselt; Status-Reset beim Seitenaufruf
ebenfalls live bestätigt (sichtbar vor, leer nach einem GET /maintenance).

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

README.md

@@ -221,6 +221,11 @@ unten). Windows/PowerShell-Wartung ist als eigener, separater Schritt
 vorgesehen (kein Testsystem dafür verfügbar) — die Kategorie existiert
 bereits, die Aktion dahinter noch nicht.
 
+Sowohl die Switche- als auch die Clients-Tabelle zeigen dieselbe
+„Zugangsdaten“-Spalte (Name + Username, oder „— keine —“), damit auf einen
+Blick erkennbar ist, welches Gerät bereits per SSH verwaltet werden kann,
+ohne extra zur Zugangsdaten-Seite wechseln zu müssen.
+
 Jeder Switch kann außerdem einen individuellen **SSH-Port** hinterlegen
 (Feld „SSH-Port“ beim Anlegen/Bearbeiten) — bleibt er leer, wird überall
 automatisch **Port 22** angenommen (`SWITCH_DEFAULT_SSH_PORT` in `app.py`).
@@ -253,11 +258,20 @@ Nur Geräte mit hinterlegten SSH-Zugangsdaten der Kategorie **Linux-Client**
   `Dpkg::Options`-Flags verhindern, dass ein Paket-Postinst-Skript auf eine
   Config-Datei-Rückfrage wartet, die nie kommt und sonst bis zum Timeout
   hängen bliebe.
-- **Neustart** (pro Gerät): `sudo reboot` per SSH. Ein abrupter
-  Verbindungsabbruch direkt danach ist erwartet (die Maschine fährt
-  herunter, bevor sie noch antworten kann) und zählt als Erfolg, kein
-  Fehler — nur ein Verbindungs-/Auth-Fehler **vor** dem eigentlichen
-  Neustart-Kommando gilt als echter Fehler.
+- **Neustart** (pro Gerät): `sudo reboot` per SSH, danach automatisch
+  weiterverfolgt bis das Gerät wieder online ist — ohne das bliebe der
+  Status für immer auf „Neustart ausgelöst“ stehen, obwohl der eigentlich
+  interessante Zeitpunkt (kommt das Gerät zurück?) noch gar nicht erfasst
+  wäre. Ablauf: das SSH-Neustart-Kommando selbst gilt als erfolgreich
+  ausgelöst, sobald die Verbindung abbricht (erwartet — die Maschine fährt
+  herunter, bevor sie noch antworten kann; nur ein Verbindungs-/Auth-Fehler
+  **vor** dem Kommando ist ein echter Fehler). Danach wartet eine kurze
+  Schonfrist (15s, damit ein zu früher Ping nicht noch die absterbende alte
+  Instanz erreicht) und pingt anschließend alle 5s (`ping -c 1 -W 2` — exakt
+  dieselbe Invocation wie das bestehende Online/Offline-Monitoring in
+  `poe.sh`), bis eine Antwort kommt oder ein Timeout von 5 Minuten erreicht
+  ist; erst dann wechselt der Status auf „wieder online“ (Erfolg) bzw. auf
+  einen Fehler, falls das Gerät nicht rechtzeitig zurückkommt.
 
 Live-Status pro Gerät (läuft/erfolgreich/fehlgeschlagen inkl. Ausgabe der
 letzten Aktion, per Klick ein-/ausblendbar) wird per Polling (`/maintenance/status`,
@@ -265,7 +279,13 @@ alle 2s solange etwas läuft, sonst alle 8s) aktualisiert, ohne die Seite neu
 zu laden. Der Job-Status lebt bewusst nur im Prozessspeicher (wie beim
 SSH-Terminal auch keine Sitzung persistiert wird) — ein Neustart von
 `poe_web.service` verwirft nur die Anzeige, nicht die auf dem Zielgerät
-bereits laufende Aktion selbst.
+bereits laufende Aktion selbst. Ein abgeschlossener **erfolgreicher** Job
+wird zusätzlich bei jedem (erneuten) Laden der Seite zurückgesetzt (Status
+wieder „Noch keine Aktion“) — ein Erfolg ist nur so lange relevant, wie man
+ihn noch live mitverfolgt, ein späterer Seitenaufruf soll keine ggf.
+stunden-/tagealte Erfolgsmeldung dauerhaft zeigen. Fehlgeschlagene Aktionen
+bleiben dagegen bewusst sichtbar, bis eine neue Aktion sie überschreibt, um
+nicht durch einen einfachen Reload versehentlich übersehen zu werden.
 
 **Sicherheitsmodell**: dieselbe `known_hosts`-Datei wie beim
 Browser-SSH-Terminal (`SSH_KNOWN_HOSTS_PATH`) — ein Host muss vorher
@@ -281,10 +301,15 @@ Live gegen ein dediziertes Testsystem verifiziert (separat vom gemeinsam
 genutzten App-Host, um dort kein echtes `apt upgrade` auszulösen): ein
 echtes `apt update && apt upgrade` (inkl. Kernel-/systemd-/netplan-Paketen)
 lief nicht-interaktiv vollständig durch (`status: success`, komplette
-`apt`-Ausgabe im Job-Verlauf sichtbar), anschließend hat der SSH-Neustart
-das Testsystem tatsächlich neu gestartet — bestätigt über `uptime -s`
-direkt nach dem Job (Boot-Zeitpunkt stimmte mit dem Auslöse-Zeitpunkt
-überein, nicht nur die vom Code erwartete Verbindungsunterbrechung).
+`apt`-Ausgabe im Job-Verlauf sichtbar); der SSH-Neustart samt
+Online-Watchdog wurde zweimal gegen dasselbe Testsystem verifiziert —
+jeweils per `uptime -s` bestätigt, dass der Boot-Zeitpunkt exakt zum
+Auslöse-Zeitpunkt des jeweiligen Jobs passte (kein False-Positive-Ping
+gegen die noch nicht heruntergefahrene alte Instanz), und dass der
+Job-Status korrekt von „wartet auf Online“ auf „wieder online“
+umgeschaltet hat. Das Zurücksetzen auf „Noch keine Aktion“ bei einem
+erneuten Seitenaufruf wurde ebenfalls live bestätigt (Status vor einem
+`GET /maintenance` noch sichtbar, danach wieder leer).
 
 Windows-Clients/PowerShell-Wartung ist bewusst **noch nicht** umgesetzt
 (kein Testsystem verfügbar) — die Kategorie „Windows-Client“ existiert in