feat 🔀 TP14 komplett: pve-Host-Mgmt VLAN1→VLAN20 (letzter Host-Umzug)

vmbr0.20 (kaputte Netzadresse statt Host-IP) auf 10.40.20.100/24 korrigiert,
Default-GW live geflippt (ifreload -a, kein Reboot). CF-Ingress bf-pve
(pve/j44d6tua-ssh) + ap1-DNS nachgezogen; dabei Alt-Bug gefunden und gefixt
(pve-mcp.bf.lan zeigte noch auf .41.173 statt .20.173).

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

docs/cf-tunnel-mapping.md

@@ -286,3 +286,13 @@ Tokens: nur im Container-Env + jederzeit via `GET /accounts/…/cfd_tunnel/<id>/
 - **Writes gehen NUR über `CF_API_TOKEN` (curl/Bearer)** — der `cloudflare`-MCP (OAuth) ist read-only (Create-Tunnel → `10000 Authentication error`).
 
 **hass-400 (2026-07-12 präzisiert):** `hass`/`vw`/`gitea` sind aktuell wieder auf **`bypass`** (App „hass, vw, gitea") → der 400 ist **rein** der Origin-Layer, **nicht Access**. HA-Log: „Received X-Forwarded-For header from an untrusted proxy **10.40.20.10**". Die reziproken bf-pve-Connectoren (macmini `.20.167`, NAS `.20.10`) fehlen in HAs `http.trusted_proxies`. **Fix** = beide IPs + `use_x_forwarded_for: true` + Core-Restart. **Kein SSH-Key auf HA `.20.105` → user-gated** (oder Zugang geben). Access-Härtung (bypass→WARP) bleibt der zweite, device-gated Schritt.
+
+---
+
+## 12. Nachtrag 2026-07-13 — pve-Host-Mgmt VLAN1→VLAN20 (letzter TP14-Host-Umzug) ✅
+Letzte in §9.2/§8 als „bleibt `.41`" geführte Origin-Klasse (`pve .41.100`, `j44d6tua`-SSH `.41.100`) nachgezogen — der pve-Host selbst (nicht nur seine Gäste/Container) ist jetzt auf VLAN20:
+- pve-Host: `vmbr0.20` (bereits als Stub vorhanden, aber mit ungültiger `address 10.40.20.0/24` — Netzadresse statt Host-IP) korrigiert auf **`10.40.20.100/24`**, live via `ifreload -a` (ifupdown2, kein Reboot). `vmbr0`/`.41.100` bleibt drauf, aber **ohne** `gateway`-Zeile (kein Doppel-Default-Route) — interim wie sw1/sw2/ap2-Mgmt bis VLAN99.
+- Default-Route auf pve geflippt: `default via 10.40.20.1 dev vmbr0.20`. Outbound (`1.1.1.1`) + SSH-Key-Login extern beide grün.
+- **Ingress `bf-pve` (`f7fdf3a6-…`) gepatcht** (via `CF_API_TOKEN`/curl, `cloudflare`-MCP weiterhin read-only): `pve.emsenhuber.net` `.41.100:8006`→`.20.100:8006`, `j44d6tua.emsenhuber.net`(ssh) `.41.100:22`→`.20.100:22`. Smoke: beide 200 über den Tunnel.
+- ap1-DNS: `pve.bf.lan`→`.20.100`. **Kollateral-Fund:** `pve-mcp.bf.lan` zeigte noch auf `.41.173` (nie nachgezogen seit TP14.1) → korrigiert auf `.20.173`.
+- Geprüft nur der Tunnel `bf-pve` (8 Hostnames + catch-all) — sonst keine `.41`-Origins mehr darin (`ccu`/`iobroker`/`z2m25`/`portainer`/`hass`/`ha-mcp` waren schon `.20.x`). `nginx-bf .41.123`/`gateway-bf .41.254` aus §8/§9.2 gehören zu anderen Tunneln/Sub-TPs, **nicht** geprüft in dieser Session.