Fix: nginx blockierte SSH-Terminal-WebSocket + DHCP-Stop bei Netzwerkaenderung

Auf der frisch installierten Test-VM zeigten sich zwei weitere reale Probleme:

1. "Verbindung testen" im Switch-Modal blieb dauerhaft auf "Getrennt"
   haengen, sobald ueber nginx (Port 80) statt direkt gegen Flask (Port
   5000) zugegriffen wurde. Ursache: etc/nginx/sites-available/poe_manager
   reichte den "Upgrade"/"Connection"-Header fuer /ws/ssh_terminal nicht
   durch -- Flask/Werkzeug lehnte den WebSocket-Handshake dadurch mit
   400 Bad Request ab, statt mit 101 Switching Protocols zu antworten.
   Live reproduziert und verifiziert (curl-Handshake direkt vs. durch
   nginx). Alle bisherigen Terminal-Tests dieser Session liefen ausschliesslich
   direkt gegen Flask, nie durch nginx, daher bis jetzt unentdeckt.
   Fix: eigener location /ws/ Block mit Upgrade-Map (Standard-nginx-Pattern)
   und grosszuegigen Timeouts fuer die lang offene Terminal-Verbindung.

2. Der Kea-DHCP-Server lief nach einer Aenderung der Host-Netzwerkkonfiguration
   unveraendert weiter, obwohl die konfigurierte Range nach einem
   IP-/Subnetzwechsel nicht mehr zum neuen Netz passen muss. Neue Funktion
   _stop_dhcp_service_if_active() stoppt Kea jetzt sowohl beim Anwenden
   als auch beim Auto-Rollback einer Netzwerkaenderung -- bewusst nur
   stoppen statt automatisch neu zu starten, die Range muss der Admin
   aktiv auf der DHCP-Seite pruefen und den Dienst dort bewusst wieder
   starten (gleiche Philosophie wie beim Rest der DHCP-Dienststeuerung).

Beide Fixes live auf der Test-VM verifiziert (WebSocket-Handshake per
curl, Netzwerk-Reapply ohne Fehler im journalctl-Log trotz nicht
installiertem Kea).

README.md

@@ -316,6 +316,13 @@ da eine Änderung nicht die Erreichbarkeit kappt).
   erreichbar ist), rollt die App automatisch auf die gesicherte
   Konfiguration zurück. Verhindert, dass ein Tippfehler bei IP/Gateway den
   Host von der Web-UI/SSH abschneidet.
+- **DHCP-Server wird vorsorglich gestoppt**: eine vorher passende Range
+  (siehe DHCP-Konfiguration oben) kann nach einer IP-/Subnetzänderung
+  plötzlich zum falschen Netz gehören. Läuft Kea beim Anwenden oder beim
+  Auto-Rollback, wird der Dienst deshalb gestoppt (nicht automatisch neu
+  gestartet — die Range muss der Admin aktiv auf der DHCP-Seite prüfen und
+  den Dienst dort bewusst wieder starten, statt dass die App mit einer
+  möglicherweise falschen Konfiguration weiterläuft oder blind rät).
 - Live gegen eine echte Ubuntu-24.04-VM verifiziert (Standard-Installation,
   Netz per DHCP über netplan/systemd-networkd bezogen) — sowohl die
   Erkennung/Statusanzeige als auch der komplette Anwenden-Pfad inkl. der
@@ -495,6 +502,13 @@ Voraussetzungen:
   so konfiguriert) — für einen echten Produktivbetrieb empfiehlt sich
   ohnehin ein WSGI-Server mit WebSocket-Unterstützung (z.B. Gunicorn mit
   `gevent`- oder `eventlet`-Worker) statt des eingebauten Dev-Servers.
+- **nginx muss den WebSocket-Upgrade für `/ws/` durchreichen** (`Upgrade`/
+  `Connection`-Header, siehe `etc/nginx/sites-available/poe_manager`) — ohne
+  das lehnt Flask den Handshake mit `400 Bad Request` ab und das Terminal
+  bleibt leer auf „Getrennt“ hängen, obwohl derselbe Aufruf direkt gegen
+  Port 5000 (an nginx vorbei) funktioniert. War auf einer frisch per
+  `install.sh` aufgesetzten Ubuntu-VM live reproduzierbar, da alle bisherigen
+  Terminal-Tests ausschließlich direkt gegen Flask liefen, nie durch nginx.
 - Da `poe_web.service` (wie im Original) als `root` läuft, kann über dieses
   Terminal im Prinzip jeder erreichbare Host per SSH kontaktiert werden —
   bewusst so gewählt, da Admins über die App ohnehin schon vollen Zugriff auf