M16: Zweisprachigkeit (DE/EN) im Experte-Tab, eigener L10n-Helfer statt String Catalog

.environment(\.locale) + Localizable.xcstrings schaltete Text(LocalizedStringKey)
live nachweislich nicht um. Ersetzt durch Core/Localization/L10n.swift
(Dictionary-Lookup je AppStorage("appLanguage")), Umschalt-Button in der Toolbar.
Vollständig übersetzt: alle Tab-Namen, alle Menü-Kategorien, kompletter
Experte-Tab inkl. Firewall-Formulare. 60 Tests grün, live bestätigt.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01YDmUd93KxsYGr2kLTotWnG

HANDOFF.md

@@ -1002,10 +1002,45 @@ Unit-Tests grün (inkl. neuer `ExpertViewModelTests` und
   bestätigte Kommentar-Änderung an einer Firewall-Regel über den neuen
   Weg
   ("funktioniert").
+- ✅ M16: Zweisprachigkeit (DE/EN) mit manuellem Umschalt-Button —
+  begonnen im Experte-Tab (App-weite Fortsetzung Tab für Tab in
+  Folgesessions geplant, wie mit dem Nutzer vereinbart). Erster Ansatz
+  (Apple String Catalog `Localizable.xcstrings` + `.environment(\.locale,
+  ...)` auf `WindowGroup`-Ebene) **live widerlegt**: der Umschalter
+  änderte selbst nach explizitem `LocalizedStringKey(...)`-Umschreiben
+  jedes betroffenen `Text`/`.help`/`Section`/Feld-Aufrufs nichts am
+  angezeigten Text ("bleibt auf deutsch") — `.environment(\.locale)`
+  steuert offenbar nur Calendar-/DateFormatter-artige APIs, nicht welche
+  Sprachtabelle `Text(LocalizedStringKey)` zur Laufzeit auflöst (das
+  scheint an Bundle-interner Locale-Verhandlung beim Start festzuhängen).
+  Fix: `Localizable.xcstrings` komplett entfernt, stattdessen eigener
+  `RouterOSAssistant/Core/Localization/L10n.swift` mit
+  `L10n.t(german, appLanguage) -> String` (Dictionary-Lookup, deutscher
+  Text als Schlüssel, Rückgabe des deutschen Texts bei fehlender
+  Übersetzung oder `appLanguage == "de"`). Jede betroffene View liest
+  `@AppStorage("appLanguage")` selbst (kein Environment-Umweg mehr) und
+  ruft `L10n.t(...)` direkt an jeder Text-/Tooltip-Stelle auf, sodass
+  SwiftUI die Abhängigkeit beim Umschalten sieht und neu rendert. Bisher
+  übersetzt: alle 6 Tab-Namen, alle 13 `RouterOSMenuCategory`-Werte, die
+  komplette Chrome von `ExpertView.swift`/`ExpertMenuDetailView.swift`
+  (Buttons, Dialoge, Platzhalter, Feld-Labels/-Hilfetexte) — inhaltlich
+  vollständig für den Experte-Tab, mit Ausnahme der noch nicht
+  übersetzten Katalog-Sektionen (siehe "Nächste Schritte"). **Build +
+  60 Tests grün, vom Nutzer live in Xcode bestätigt** ("das sieht gut
+  aus").
 
 ## Nächste Schritte
 
-1. WLAN (M5) an einem Gerät mit echtem WLAN-Chip nachholen.
+1. M16 fortsetzen: restliche `RouterOSSchemaCatalog.swift`-Sektionen
+   (interfaceFamily, ipFamily, routingFamily, vpnFamily, wirelessFamily,
+   queueFamily, systemFamily, toolFamily) in
+   `Core/Localization/L10n.swift`s `translations`-Dictionary übersetzen —
+   Firewall-Familie ist bereits vollständig, mit dem Nutzer vereinbart
+   Tab für Tab weiterzumachen. Anschließend dieselbe `L10n.t(...)`-
+   Umstellung auf die übrigen Tabs (Verbinden/Einrichten/Geräte/
+   Sicherungen/Übersicht) ausrollen — dort läuft aktuell noch alles auf
+   festen deutschen String-Literalen ohne Sprachumschaltung.
+2. WLAN (M5) an einem Gerät mit echtem WLAN-Chip nachholen.
 2. Rest von M7: Fehlerzustände/Politur, REST-Schreibtest an einem Gerät
    mit aktivem `www-ssl`.
 3. M9 UI (Einfach/Experte-Modusumschalter im Einrichten-Tab selbst) noch