feat(dns): publish public names as proxied CNAMEs to the Cloudflare Tunnel

Gateway target -> fc81938b-...cfargotunnel.com, --cloudflare-proxied globally,
L4 service publishers (unifi, crafty-mc) pinned DNS-only, Plex web UI and
Headlamp disowned (LAN/VPN-only). L0 internal-services-publish-no-public-dns
gains assertion (9) tying the Gateway target to the tunnel UUID, requiring
cloudflare-proxied=false on every service-source publisher, and keeping the
tunnel's 404 list and the unpublished set consistent. L2 dns-exposure fixture
opts out of proxying.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

runbooks/plex-remote-access.md

@@ -11,6 +11,19 @@ env — note `ADVERTISE_IP` is deliberately NOT set; see "Why not the Gateway UR
 **Related:** `runbooks/plex-quicksync.md` and `runbooks/plex-claim.md` — the other two Plex
 procedures with a manual last mile.
 
+## The Plex web UI is LAN/VPN-only (2026-11-08)
+
+When public DNS moved to the Cloudflare Tunnel (`runbooks/cloudflare-tunnel.md`, Phase 2), the
+operator kept **Plex off the tunnel**. `catalog/plex.yaml` is now `exposure: internal`, so the
+`plex.home.keithjackson.dev` route carries `external-dns ... controller: none` and its public record
+is deleted; the tunnel also 404s `plex` and `plex-vip`. On the LAN (and over WireGuard) the web UI
+at `https://plex.home.keithjackson.dev` works exactly as before through PiHole's split-horizon answer.
+
+**Remote streaming is unaffected** — it never used that name. It is the path below: plex.tv hands
+clients the `plex.direct` URL (`ADVERTISE_IP`) for the L4 VIP `192.168.2.24`, reached through the
+WAN **tcp/32400** forward. That forward must stay open when the WAN 80/443 forwards are closed after
+the tunnel cut-over. Remote users use app.plex.tv, not our hostname.
+
 ## What was actually broken (measured 2026-10-03)
 
 Plex was serving correctly and was reachable on the LAN. Two independent things stopped remote
@@ -44,9 +57,10 @@ either way — this repo has no such vantage point and must not pretend otherwis
 router by hand, so it must never move on a reschedule.
 
 While in the router, **check what else is bound to the WAN interface.** If remote management is
-listening on 443 (see the certificate measurement above), move it or disable it — otherwise the
-Gateway's 80/443 forward is shadowed and the Plex *web UI* over the internet stays broken even
-though remote *streaming* works. These are two separate paths and they fail independently.
+listening on 443 (see the certificate measurement above), move it or disable it. (Historical: this
+used to shadow the Gateway's 80/443 forward for the Plex *web UI* over the internet. Since
+2026-11-08 the web UI is LAN/VPN-only and public HTTP(S) goes through the Cloudflare Tunnel, so the
+80/443 forwards are retired; only tcp/32400 matters here.)
 
 Confirm the VIP is actually answering on the LAN first, so a failure later is unambiguous: