Fix: DHCP-Range wurde nie gegen das tatsaechliche Netz geprueft

Auf der Test-VM liess sich der Dienst mit einer gespeicherten Range
(192.168.81.203-212) starten, obwohl das erkannte Netz des Interfaces
192.168.80.0/24 war -- die Range gehoerte also zu einem komplett anderen
Subnetz. _dhcp_config_is_complete() prophfte bisher nur, ob Range Start/
Ende ueberhaupt ausgefuellt waren, nie ob sie zum echten Netz passen.

Neue Funktion _dhcp_matching_network(interface, start, end) validiert die
Range jetzt an drei Stellen: beim Speichern (save_dhcp_config), beim
Schreiben der Kea-Datei (write_dhcp_file) und beim Starten des Dienstes
(dhcp_service_action=enable_restart) -- jede der drei Aktionen wird mit
einer genauen Fehlermeldung abgelehnt, statt eine zum Netz nicht passende
Range durchzulassen.

Die Pruefung beruecksichtigt dabei ALLE IPv4-Adressen des Interfaces, nicht
nur die erste -- ein Interface kann mehrere IPs/Subnetze gleichzeitig
tragen (Alias-IPs). Dafuer wurde _detect_interface_network() in eine neue
_detect_interface_networks() (Mehrzahl, alle Adressen) plus einen duennen
Wrapper fuer die primaere/erste Adresse aufgeteilt -- alle bisherigen
Aufrufer (Anzeige auf der DHCP-Seite, Host-Netzwerkeinstellungen) bleiben
unveraendert auf der primaeren Adresse.

Echte Mehrfach-Ranges gleichzeitig (mehrere Subnetze parallel, z.B. auf
verschiedenen Interfaces) sind bewusst nicht Teil dieses Fixes -- laut
Ruecksprache ein separater, groesserer Umbau (DB-Tabelle statt globaler
Range, mehrere subnet4-Bloecke in der Kea-Config, Listen-UI) und als
naechster Schritt vorgesehen.

Live auf der Test-VM verifiziert: falsche Range wird beim Speichern,
Schreiben und Starten korrekt abgelehnt, eine zum erkannten Netz passende
Range weiterhin akzeptiert -- keine Fehler im journalctl-Log.

README.md

@@ -263,12 +263,22 @@ der aktiv weiterentwickelte Nachfolger und bildet „globaler Wert, pro Client
   schreibt die vollständige, generierte Kea-JSON-Konfiguration an den
   konfigurierten Ausgabepfad. Wirksam wird sie erst nach einem
   Dienst-Neustart über den separaten Button.
-- **Range ist Pflicht**: kein vorausgefüllter Default für Range/DNS mehr
-  (nur Platzhaltertext) — ohne eingetragene Range schreibt „In Datei
-  schreiben“ nichts und „Aktivieren & (neu) starten“ verweigert den Start,
-  statt den Dienst mit einer geratenen, zum echten Netz eventuell nicht
-  passenden Range laufen zu lassen. Gateway ist separat und optional
+- **Range ist Pflicht und muss zu einem echten Netz passen**: kein
+  vorausgefüllter Default für Range/DNS mehr (nur Platzhaltertext) — ohne
+  eingetragene Range schreibt „In Datei schreiben“ nichts und „Aktivieren &
+  (neu) starten“ verweigert den Start. Zusätzlich wird die Range beim
+  Speichern, Schreiben UND Starten gegen die tatsächlich am gewählten
+  Interface vorhandenen IPv4-Netze geprüft (ein Interface kann mehrere IPs/
+  Subnetze gleichzeitig tragen, z.B. Alias-IPs — alle werden berücksichtigt).
+  Passt die Range zu keinem davon (z.B. weil sich das Netz des Hosts seit
+  dem letzten Speichern geändert hat), wird die Aktion mit einer genauen
+  Fehlermeldung abgelehnt, statt den Dienst mit einer zum echten Netz nicht
+  passenden Range laufen zu lassen — live auf einer echten Fehlkonfiguration
+  reproduziert und verifiziert. Gateway ist separat und optional
   überschreibbar (Default: automatisch erkanntes Gateway des Interfaces).
+  (Mehrere DHCP-Ranges gleichzeitig — z.B. auf unterschiedlichen Interfaces
+  — sind aktuell nicht unterstützt, die Konfiguration ist auf eine globale
+  Range/ein Interface ausgelegt; als nächster Ausbauschritt vorgesehen.)
 - **Ampel im Topbar**: neben dem Prüfintervall-Timer zeigt ein grüner/roter
   Punkt, ob der Kea-Dienst läuft — nur sichtbar mit `settings_dhcp.view`.
 - Reservierungen mit aktiven eigenen Options zeigen in der Tabelle, welche