DHCP: Subnetze deaktivierbar + 47 verifizierte Standard-Optionen

1. Subnetze koennen einzeln deaktiviert werden (enabled-Spalte), ohne sie
   loeschen zu muessen -- werden dann bei "In Datei schreiben" und
   "Aktivieren & (neu) starten" komplett uebersprungen. Bewusst nicht als
   "ungueltig" gewertet (kein Fehler/keine Warnung), da eine deaktivierte
   Zeile absichtlich kein echtes Netz braucht. Toggle-Button in der
   Subnetz-Tabelle, deaktivierte Zeilen abgeblendet mit "Deaktiviert"-Pill.

2. 47 kuratierte Standard-DHCP-Optionen vorbefuellt (analog den
   "Predefined Options" eines Windows-DHCP-Servers) -- Router/DNS-Server/
   Domain-Name/Lease-Zeiten ausgenommen, dafuer gibt es bereits eigene
   Felder. Alle Namen live gegen eine echte Kea-2.4.1-Instanz verifiziert:
   jede der 49 Kandidaten-Optionen einzeln per kea-dhcp4 -t getestet, 47
   akzeptiert (2 falsch geratene Namen verworfen: nis-domain-name statt
   nis-domain, nisplus-domain statt nisplus-domain-name).

   Wichtig fuer Kea-Kompatibilitaet: Standard-Optionen bekommen KEIN
   eigenes option-def in der generierten Konfiguration (neue is_standard-
   Spalte in dhcp_option_defs) -- Kea kennt sie bereits nativ, eine
   Neudefinition haette die eingebaute dupliziert. Nur echte eigene/
   herstellerspezifische Options bekommen weiterhin ein option-def.
   Live verifiziert: option-def bleibt bei gesetztem Standard-Options-Wert
   leer, option-data enthaelt den Wert korrekt, kea-dhcp4 -t besteht,
   echter Dienstneustart mit der Config erfolgreich.

   Einmalige Migration (Guard wie bei den anderen Schema-Migrationen) --
   ein vom Admin bewusst geloeschter Standard-Eintrag wird nach einem
   Neustart nicht stillschweigend wieder angelegt.

Ausserdem in dieser Session zuvor gefixt (siehe vorherige Commits): der
falsche Kea-Schluessel lease-file->name, der jeden Dienststart blockierte,
sowie der 'Jetzt pruefen'-Button, der den Topbar-Countdown nur auf dem
Dashboard aktualisierte.

README.md

@@ -265,15 +265,32 @@ der aktiv weiterentwickelte Nachfolger und bildet „globaler Wert, pro Client
   abzubrechen) und bei „Aktivieren & (neu) starten“ (verweigert den Start,
   falls kein einziges gültiges Subnetz mehr existiert). Live auf einer
   echten Fehlkonfiguration reproduziert und verifiziert.
-- **Eigene Options** (`dhcp_option_defs`/`dhcp_option_values`, analog den
-  „Vordefinierten Optionen und Werten“ eines Windows-DHCP-Servers): Code,
-  Name, Kea-Datentyp und Beschreibung frei definierbar (z.B. herstellerspezifische
-  Options wie eine Terminal-Boot-URL). Jede Option hat einen **globalen**
-  Wert sowie optional einen **Wert pro Client** — ein Client-Override
-  überschreibt den globalen Wert ausschließlich für dieses eine Gerät
-  (technisch: globale Werte landen im Top-Level `option-data`, Overrides im
-  `option-data` der jeweiligen Kea-Reservierung, was Kea automatisch pro
-  Client Vorrang geben lässt).
+- **Subnetze einzeln deaktivierbar**: ein Subnetz lässt sich ohne Löschen
+  pausieren (`enabled`-Flag) — wird dann bei „In Datei schreiben“ und
+  „Aktivieren & (neu) starten“ komplett ignoriert (kein Fehler, bewusst
+  kein "ungültig", da das Fehlen des Netzes hier Absicht ist), statt es
+  jedes Mal neu anlegen zu müssen.
+- **DHCP-Options** (`dhcp_option_defs`/`dhcp_option_values`): eine kuratierte
+  Auswahl an **47 Standard-Optionen** (analog den „Vordefinierten Optionen“
+  eines Windows-DHCP-Servers — z.B. NTP-/WINS-/TFTP-/SMTP-Server, Boot-Datei,
+  Domain-Search, IP-Forwarding) ist automatisch vorbefüllt; Router/DNS-Server/
+  Domain-Name/Lease-Zeiten sind bewusst ausgenommen, da dafür bereits eigene,
+  dedizierte Felder existieren (Subnetze bzw. globale Einstellungen oben).
+  Alle 47 Namen sind live gegen eine echte Kea-2.4.1-Instanz verifiziert
+  (`kea-dhcp4 -t`, jede Option einzeln getestet). Standard-Optionen bekommen
+  bewusst **kein eigenes `option-def`** in der generierten Konfiguration —
+  Kea kennt sie bereits nativ, eine Neudefinition würde die eingebaute
+  duplizieren; nur zusätzlich angelegte, wirklich eigene/herstellerspezifische
+  Options (z.B. eine Terminal-Boot-URL) bekommen eines. Beide Arten
+  funktionieren im UI identisch: Code, Name, Kea-Datentyp und Beschreibung
+  frei definierbar, jede Option hat einen **globalen** Wert sowie optional
+  einen **Wert pro Client** — ein Client-Override überschreibt den globalen
+  Wert ausschließlich für dieses eine Gerät (technisch: globale Werte landen
+  im Top-Level `option-data`, Overrides im `option-data` der jeweiligen
+  Kea-Reservierung, was Kea automatisch pro Client Vorrang geben lässt).
+  Ein versehentlich vom Admin gelöschter Standard-Eintrag wird nach einem
+  Neustart nicht automatisch wieder angelegt (einmalige Migration, kein
+  Zurückschreiben bei jedem Start).
 - **Reservierungen**: für jedes aktive Gerät mit gültiger MAC + IP wird eine
   Kea-Reservierung im **passenden Subnetz** erzeugt (die IP entscheidet, zu
   welchem der ggf. mehreren konfigurierten Subnetze ein Gerät gehört); der