DuckDNS Let's Encrypt erfolgreich: Ursache war ein falscher aliases-Eintrag

Tatsaechliche Ursache der deploy_challenge-Fehlschlaege gefunden: ein
ueberfluessiger/falscher aliases-Eintrag (alias: datametric360 ohne
.duckdns.org) in der DuckDNS-Add-on-Konfiguration, zusammen mit
accept_terms: false. Nach Entfernen von aliases und accept_terms: true lief
die Zertifikatsanfrage sofort durch. Der DNS-Server war entgegen der
vorherigen Vermutung kein Faktor - Erfolg trat auch mit dem Speedport als
DNS ein.

configuration.yaml's alter http:-Block entfernt, HA migriert SSL-Pfade und
interne/externe URL jetzt ueber die Oberflaeche (Einstellungen > System >
Netzwerk). Dabei eine HA-Eigenheit dokumentiert: Netzwerkaenderungen muessen
innerhalb 5 Minuten per Dialog bestaetigt werden, sonst automatischer
Rollback.

HA ist jetzt per HTTPS mit gueltigem Let's-Encrypt-Zertifikat erreichbar.

AGENTS.md

@@ -205,11 +205,11 @@ capacitor/iframe/browser (`umgebung.ts`), types + entity table (`types.ts`), fac
 - [x] Decide broker reachability for the vehicle — port-forward 8883 (not VPS bridge), decided
       2026-08-11; DuckDNS hostname `datametric360.duckdns.org` set up and reliably updating,
       port-forward 8883 done on the Speedport Smart 4 Plus, FMM003 confirmed sending data. Let's
-      Encrypt for HA's own local UI deliberately dropped (`deploy_challenge` DNS-01 hook failed
-      reproducibly inside the DuckDNS add-on container specifically — root cause not found despite
-      thorough diagnosis; not worth pursuing since HA is Tailscale-only anyway, see
-      COMPANION_APP_ARCHITECTURE.md §5 item 2a for the full writeup). `configuration.yaml`'s
-      `http: ssl_certificate/ssl_key` block stays commented out permanently.
+      Encrypt for HA's own local UI is now working too (root cause of the earlier DNS-01 failures
+      was a stray `aliases` entry in the DuckDNS add-on config, not DNS/network — see
+      COMPANION_APP_ARCHITECTURE.md §5 item 2a for the full writeup). HA's SSL config now lives in
+      Settings → System → Network (UI), not `configuration.yaml`'s old `http:` block, which was
+      removed after HA started migrating/ignoring it.
 - [ ] MQTT Client Type on the FMM003: "Custom server" (value 3, seen in Configurator help text) was
       not selectable in practice — use **"AWS IoT Custom"** pointed at the own broker instead
       (confirmed working by two independent community reports); verify once the device is live