DuckDNS: Let's Encrypt bewusst fallen gelassen, Portfreigabe erledigt

deploy_challenge (DNS-01) scheiterte reproduzierbar am dig-Aufruf im
DuckDNS-Add-on-Container selbst, obwohl DuckDNS den TXT-Eintrag nachweislich
korrekt setzt und dieser ueberall sonst (PC, HA-SSH-Konsole) sofort sichtbar
war - Ursache innerhalb des Containers blieb trotz gruendlicher Diagnose
ungeklaert. Entscheidung: abschalten statt weiter debuggen, da HA ohnehin
nur ueber Tailscale erreichbar ist. DuckDNS selbst (IP-Update) laeuft
zuverlaessig weiter - das ist der fuer den FMM003-Pfad relevante Teil.

configuration.yaml's http:-Block bleibt deshalb dauerhaft auskommentiert.
Portfreigabe 8883 und FMM003-Datenversand sind bestaetigt erledigt.

COMPANION_APP_ARCHITECTURE.md

@@ -347,10 +347,26 @@ else in this document:
    App (§4, dort bleibt es bei Cloudflare Tunnel — kein Widerspruch, siehe dort die Begründung, warum
    ein eng begrenzter, zertifikatsgesicherter Port etwas anderes ist als HA selbst offenzulegen).
    **Umsetzungsstand (2026-08-11):** DuckDNS-Hostname `datametric360.duckdns.org` angelegt und als
-   Add-on in HA eingerichtet (inkl. eigenständigem Let's-Encrypt-Zertifikat für die HA-Oberfläche
-   selbst — unabhängig von den MQTT-Zertifikaten unten, siehe dortige Anmerkung). Router bestätigt
-   **Dual-Stack** (kein DS-Lite) — die Portfreigabe funktioniert damit grundsätzlich. **Noch offen:**
-   die Portfreigabe selbst am Speedport Smart 4 Plus.
+   Add-on in HA eingerichtet, aktualisiert zuverlässig die öffentliche IP — das ist der für den
+   FMM003-Pfad tatsächlich entscheidende Teil. Router bestätigt **Dual-Stack** (kein DS-Lite), die
+   Portfreigabe 8883 am Speedport Smart 4 Plus ist eingerichtet, FMM003 sendet bestätigt Daten.
+
+   **Let's-Encrypt-Zertifikat für die HA-Oberfläche selbst — bewusst NICHT umgesetzt:** Der
+   `deploy_challenge`-Hook (DNS-01, TXT-Eintrag via DuckDNS-API) scheiterte reproduzierbar mit
+   `timeout 120s` beim Warten auf den eigenen TXT-Eintrag. Diagnose ausführlich durchgeführt: der
+   TXT-Eintrag wird von DuckDNS korrekt gesetzt (manuell per `txt=`-Parameter bestätigt, `OK`/
+   `UPDATED`) und ist öffentlich sofort sichtbar (bestätigt per `nslookup` gegen `8.8.8.8` vom PC
+   *und* per `dig` aus der HA-eigenen SSH-Konsole gegen den internen Supervisor-Resolver
+   `127.0.0.11`/`172.30.32.3` — beide sahen den aktuellen Challenge-Wert sofort). Trotzdem scheiterte
+   ausgerechnet der interne `dig`-Aufruf *im DuckDNS-Add-on-Container selbst* wiederholt (auch nach
+   Wechsel des HA-DNS-Servers auf `1.1.1.1` und komplettem Host-Neustart, `host_network: false`
+   bestätigt — Ursache innerhalb des Add-on-Containers blieb ungeklärt). **Entscheidung:** Let's
+   Encrypt im DuckDNS-Add-on deaktiviert statt weiter zu debuggen — verhältnismäßig, weil HA laut
+   Sicherheitsprinzip oben sowieso nie öffentlich exponiert wird und nur über Tailscale erreichbar
+   ist (das verschlüsselt den Transport bereits); ein eigenes Zertifikat für die lokale UI ist damit
+   ein Nice-to-have, kein Sicherheitserfordernis. Der `http: ssl_certificate`/`ssl_key`-Block in
+   `configuration.yaml` bleibt deshalb dauerhaft auskommentiert (er hatte HA sonst am Start
+   gehindert, solange die referenzierten Dateien nie erzeugt wurden).
 
    Nebenbei geklärt: ein Vorschlag, stattdessen komplett auf Cloudflare zu setzen, wurde geprüft und
    **ist keine Alternative** — Cloudflare Tunnel kann kein rohes MQTT/TCP transportieren (nur HTTP),