poe.sh: parallele Geräte-Prüfung + echte PoE-Erfolgskontrolle

Nach einem echten Import (46 Geräte, 8 Switche aus dem Altsystem)
zeigten sich zwei Probleme in der Hintergrund-Prüfschleife:

- Geräte wurden strikt sequentiell geprüft (eine einzige "while read"-
  Schleife) -- ein einzelnes ausgefallenes Gerät mit ebenfalls nicht
  erreichbarem Switch (bis zu 5s expect-Timeout je Verbindungsschritt)
  verzögerte die Prüfung aller nachfolgenden Geräte. Jede Geräte-Prüfung
  läuft jetzt als eigener Hintergrund-Job (& + wait), über Process
  Substitution statt einer Pipe, damit wait die Jobs auch tatsächlich
  erfasst (bei "cmd | while ...; done" liefe die Schleife sonst in
  einer eigenen Subshell).
- disable_poe()/enable_poe() haben unabhängig vom tatsächlichen Ergebnis
  der SSH/expect-Sitzung immer wie ein Erfolg gewirkt -- lief die
  Verbindung in einen Timeout (Switch nicht erreichbar, falsche
  Zugangsdaten, falscher Port), endete das expect-Skript trotzdem mit
  Exit-Code 0, poe.sh loggte fälschlich "PoE deaktiviert"/"PoE
  aktiviert", obwohl am Switch nichts passiert war. Jeder kritische
  expect-Schritt hat jetzt einen eigenen timeout-Zweig mit explizitem
  "exit 1"; poe.sh wertet den Rückgabewert aus und loggt bei einem
  nicht erreichbaren/ablehnenden Switch stattdessen klar, dass die
  PoE-Aktion fehlgeschlagen ist. Gilt für die Prüfschleife, den
  manuellen Neustart (poe.sh restart <mac>) und damit auch den
  Dashboard-Neustart-Button.

Live verifiziert: alle 46 Geräte innerhalb von ~2s geprüft (statt
sequentiell), alle 43 offline erkannten Geräte mit Switch-Zuordnung
zeigten korrekt die neue Fehlermeldung, da die realen Switch-IPs vom
Test-Host aus nicht erreichbar sind -- vorher hätte das fälschlich als
43x "PoE deaktiviert/aktiviert" geloggt.

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

README.md

@@ -91,9 +91,12 @@ Die App ermöglicht:
   (vom PoE-Server) aufgebaut, nie vom Browser/Client aus.
 - **Granulares Rechtesystem mit Gruppen** (neu, siehe unten) statt der
   ursprünglichen reinen Admin/User-Unterscheidung.
-- **Gleiche Kernlogik**: Datenbankschema (erweitert um Gruppen/Rechte),
-  Login, PoE-Restart-Mechanismus (`poe.sh` per SSH/`expect` auf die
-  Aruba-Switche) sind ansonsten unverändert.
+- **Gleiche Kernlogik**: Datenbankschema (erweitert um Gruppen/Rechte) und
+  Login sind ansonsten unverändert. Der PoE-Restart-Mechanismus selbst
+  (`poe.sh` per SSH/`expect` auf die Aruba-Switche) wurde dagegen
+  überarbeitet — parallele statt sequentielle Geräte-Prüfung und echte
+  Erfolgskontrolle statt blind angenommenem Erfolg, siehe
+  [Geräte-Prüfung](#geräte-prüfung-poesh).
 - **Aufgeräumtes Backend**: konsistente, konfigurierbare Pfade (`POE_DB_PATH`,
   `POE_SCRIPT`, `POE_LOG_GLOB`, …) statt hart codierter/inkonsistenter Pfade;
   Secret-Key und Fernet-Key werden beim ersten Start automatisch generiert
@@ -476,6 +479,51 @@ Betrieb bestätigt: ein tatsächlicher, unreservierter Client im Testnetz
 („shellyhtg3-...“) hat sich selbstständig eine IP aus dem Pool geholt und
 wurde korrekt mit der „Ohne Reservierung“-Markierung angezeigt.
 
+## Geräte-Prüfung (`poe.sh`)
+
+Der Hintergrund-Check-Dienst (`rpi-check.service`, ruft `poe.sh` ohne
+Argument auf) prüft in einer Endlosschleife alle Geräte per Ping und
+startet bei Ausfall automatisch den PoE-Port neu, über den ein Gerät am
+zugeordneten Switch hängt (`expect`, siehe unten). Zwei Korrekturen nach
+einem echten Import mit deutlich mehr Geräten (46 statt einer Handvoll
+Testgeräte):
+
+- **Parallele statt sequentielle Prüfung**: vorher wurde jedes Gerät strikt
+  nacheinander in einer einzigen Schleife geprüft — ein einzelnes bereits
+  ausgefallenes Gerät mit ebenfalls nicht erreichbarem Switch (jeder
+  `expect`-Verbindungsschritt bis zu 5s Timeout) hat dadurch die Prüfung
+  aller nachfolgenden Geräte in der Liste verzögert; bei vielen gleichzeitig
+  ausgefallenen Geräten konnte ein Prüfdurchlauf so erheblich länger dauern
+  als das eigentlich konfigurierte Intervall. Jetzt läuft jede
+  Geräte-Prüfung (Ping + ggf. PoE-Neustart) als eigener Hintergrund-Job
+  (`&` + `wait` am Ende des Durchlaufs, über Process Substitution statt
+  einer Pipe, damit `wait` die Jobs auch tatsächlich erfasst) — mehrere
+  Geräte, auch an unterschiedlichen Switchen, werden dadurch gleichzeitig
+  geprüft statt einzeln nacheinander.
+- **Echte Erfolgskontrolle statt blind angenommenem Erfolg**: `disable_poe()`/
+  `enable_poe()` haben vorher unabhängig vom tatsächlichen Ergebnis der
+  SSH/`expect`-Sitzung immer wie ein Erfolg gewirkt — lief die Verbindung
+  zum Switch in einen Timeout (Switch nicht erreichbar, falsche
+  Zugangsdaten, falscher Port), endete das `expect`-Skript trotzdem mit
+  Exit-Code 0, und `poe.sh` loggte fälschlich „PoE deaktiviert“/„PoE
+  aktiviert", obwohl am Switch nichts passiert war. Jeder kritische
+  `expect`-Schritt (Verbindungsaufbau, `configure terminal`-Prompt,
+  Interface-Prompt, Bestätigung des `power-over-ethernet`-Kommandos) hat
+  jetzt einen eigenen `timeout`-Zweig mit explizitem `exit 1`; `poe.sh`
+  wertet diesen Rückgabewert aus und loggt bei einem nicht erreichbaren
+  oder ablehnenden Switch stattdessen klar „Switch ... nicht erreichbar
+  oder Kommando abgelehnt — PoE-Deaktivierung/-Reaktivierung
+  fehlgeschlagen“, ohne einen Neustart vorzugaukeln, der nie stattgefunden
+  hat. Gilt für die automatische Prüfschleife, den manuellen Neustart
+  (`poe.sh restart <mac>`) und damit auch für den Dashboard-Neustart-Button.
+
+Live nach einem echten Import (46 Geräte, 8 Switche aus dem Altsystem)
+verifiziert: alle 46 Geräte wurden innerhalb von ~2 Sekunden geprüft (statt
+sequentiell), und alle 43 als offline erkannten Geräte mit Switch-Zuordnung
+zeigten korrekt die neue Fehlermeldung, da die realen Switch-IPs
+(192.168.200.x) vom Test-Host aus nicht erreichbar sind — vorher hätte das
+fälschlich als 43× „PoE deaktiviert“/„PoE aktiviert“ geloggt.
+
 ## Netzwerkeinstellungen des Hosts (Systemeinstellungen)
 
 Eigene, klar getrennte Funktion von obigem DHCP-*Server*: hier geht es um