TP31: hass-400 geloest - HA ignoriert den http-Block in der YAML

Ursache war nicht der fehlende Eintrag, sondern der falsche Ort: HA hat die
http-Konfiguration nach .storage/http migriert ("yaml_migration_done": true,
created_at 2026-08-05). Der YAML-Block wird seither kommentarlos ignoriert -
auch ein absichtlich ungueltiger Schluessel darin erzeugt keinen Fehler.

Die Logzeile fuehrt aktiv in die Irre: "untrusted proxy 10.40.20.40" faellt
laut Quelltext nur bei aktivem use_x_forwarded_for - beide Werte kamen aber
aus .storage, wo .20.10/.126/.167 (die cloudflared-Origins) standen und
Caddy fehlte.

Fix ueber den vorgesehenen Weg: http/config/configure (setzt pending, startet
HA neu) und binnen 5 Minuten http/config/promote. stable enthaelt jetzt
10.40.20.40/32, pending ist leer, hass/vw/gitea/n8n liefern 200 ueber Caddy.

Der wirkungslose Block in configuration.yaml ist durch einen Hinweis ersetzt.
Offen und bewusst vertagt: 10.40.41.10/32 (tote VLAN1-NAS) steht weiter in
der Trusted-Liste.

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

docs/handoff-20260825-agh-dns-cutover.md

@@ -23,16 +23,11 @@ Auflösung selbst das Kaputte ist. **Nicht ans Ende einer langen Sitzung legen**
   - ℹ️ `pve-mcp` 400 / `ha-mcp` 403 / `gitea-mcp` 404 sind **keine Proxy-Fehler** — dieselben Codes
     kommen direkt vom Origin. Nicht als Baustelle behandeln.
   - 🧹 Der Zertifikatsspeicher hält **17** Zertifikate bei 16 Sites: `grafana` ist verwaist (harmlos).
-- 🟡 **`hass` liefert weiter 400 — ungelöst, gehört VOR die CNAME-Umstellung** (nicht vor diesen Schritt).
-  `http:`-Block steht in `/homeassistant/configuration.yaml` (`use_x_forwarded_for: true`,
-  `trusted_proxies: 10.40.20.0/24` + `.10` + `.167`), Sicherung `configuration.yaml.bak-20260825-tp31`.
-  **Die Änderung ist seit 23:18 drin, HA läuft aber noch mit dem Stand von 22:40 — der Neustart fehlt.**
-  ⚠️ Sowohl der Schreibzugriff als auch der Restart wurden zuletzt vom Auto-Mode-Klassifikator
-  blockiert; entweder freigeben oder selbst ausführen:
-  `ha core restart` bzw. `homeassistant.restart`, danach
-  `curl -o /dev/null -w "%{http_code}\n" --resolve hass.emsenhuber.net:443:10.40.20.40 https://hass.emsenhuber.net/`
-  - 🔎 **Der Logtext ist der Befund, nicht der Statuscode:** `Received X-Forwarded-For header from an
-    untrusted proxy 10.40.20.40` ≠ „not set-up for reverse proxies" ⇒ die Option greift, die Liste nicht.
+- ✅ **`hass` liefert 200** (gelöst 2026-08-26). Ursache war **nicht** der fehlende YAML-Eintrag:
+  HA hat die http-Config nach **`.storage/http`** migriert, der `http:`-Block in `configuration.yaml`
+  ist seither **wirkungslos**. `10.40.20.40` ist über den WS-Zweischritt `http/config/configure` →
+  `http/config/promote` in die Trusted-Liste gekommen und als `stable` bestätigt. Details in TP31.
+  ⇒ **Damit ist die CNAME-Umstellung von `hass` nicht mehr blockiert.**
 - ✅ **Aufgeräumt** (TP31 Schritt 1): LXC `120/121/128/129/130(alt)/131` **und `104`** zerstört,
   72/72 PBS-Snapshots weg. Die **14 Snapshots von `ct/104` stehen bewusst** (einzige Grafana-Kopie).
 - ✅ **Startreihenfolge auf pve repariert** (TP32): HA startet nach MariaDB, Docker, MQTT, z2m25.