docs: record ecowitt lan-only ingress decision

LAN-only Host-Bind 192.168.178.58:8123 fuer den Ecowitt-HTTP-Push
dokumentiert: DECISIONS-Eintrag (loest Phase-2-Frage), Architektur-Master
Ausnahme 10, SERVICE_CATALOG. Webhook + LAN-Endpunkt verifiziert; offen
bleibt nur die GW3000-Customized-Server-Konfiguration am Geraet.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

docs/DECISIONS.md

@@ -11,6 +11,26 @@ in `HOMELAB_ARCHITECTURE_MASTER_V2.md` §13, `docs/MASTER_TODO.md` (Geparkt),
 
 ---
 
+## 2026-06-13 - Ecowitt-Ingress: LAN-only Host-Bind 8123 umgesetzt
+
+**Entscheidung:** Home Assistant bekommt einen LAN-only Host-Bind
+`192.168.178.58:8123:8123` (nur LAN-IP, nicht `0.0.0.0`/WAN). Das Ecowitt-GW3000
+pusht per HTTP direkt an den HA-Webhook. Damit ist die offene
+Phase-2-Entscheidung (Eintrag 2026-06-12) zugunsten des LAN-Bind-Fallbacks
+entschieden; ein Umbau des globalen Traefik HTTP-zu-HTTPS-Redirects entfaellt,
+weil Ecowitt rein im LAN pusht und Traefik gar nicht braucht.
+
+**Kontext:** Der globale `web`->`websecure`-Redirect auf EntryPoint-Ebene laesst
+sich nicht sauber selektiv aushebeln. Der LAN-Bind ist analog zur dokumentierten
+InfluxDB-8181-Ausnahme, WAN-sicher (FRITZ!Box forwardet nur 443 auf Traefik) und
+ohne Traefik-Umbau. Der HA-Webhook ist nicht `local_only`; Schutz ist die
+128-bit-Zufalls-Webhook-ID. Restrisiko: der Pfad ist theoretisch auch ueber
+Traefik/443 erreichbar, praktisch aber unratbar.
+
+**Review-Trigger:** Wenn der Webhook haerter abgesichert werden soll
+(Traefik-IPAllowList auf `/api/webhook/` oder `local_only`), oder bei Ausbau
+auf Ecowitt-Langzeitspeicherung in InfluxDB.
+
 ## 2026-06-12 - Home Assistant als Container im GitOps-Stack
 
 **Entscheidung:** Home Assistant laeuft neu als `homeassistant` Container im