feat(dns): PiHole answers an explicit LAN name list, not a zone wildcard

Public names are proxied CNAMEs to the Cloudflare Tunnel since PR #156 and
work from the LAN, so they should resolve publicly there too. Replace the
address=/${BASE_DOMAIN}/ wildcard with explicit entries: the LAN-only names
(derived from every controller:none HTTPRoute), gitea/nextcloud (off
Cloudflare's 100 MB / 100 s limits), keycloak/auth, and the L4 VIPs.

Add L0 check pihole-lan-names, mutation-tested. Correct docs that still
described public names as CNAME to wan. and the cloudflared entrypoint comment.

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

platform/gateway/gateway.yaml

@@ -30,8 +30,10 @@ metadata:
     # applies BEFORE it reads this target. Those same names map to `http_status:404` in the tunnel's
     # ingress rules, so even a hand-made record cannot reach them through the tunnel.
     #
-    # LAN and in-cluster clients are unaffected: PiHole and CoreDNS answer ${BASE_DOMAIN} with
-    # ${GATEWAY_VIP} directly (split-horizon), so they never take this public path.
+    # In-cluster clients are unaffected: CoreDNS answers ${BASE_DOMAIN} with ${GATEWAY_VIP} directly
+    # (split-horizon). LAN clients use PiHole's EXPLICIT list (catalog/pihole.yaml, since 2026-11-09):
+    # LAN-only names and gitea/nextcloud/keycloak/auth get ${GATEWAY_VIP}; every other published
+    # name takes this public path through Cloudflare, from the LAN as from anywhere.
     #
     # `wan.${BASE_DOMAIN}` (platform/externaldns/ddns.yaml) is NO LONGER a target of anything here;
     # it stays only as the WireGuard udp/51820 endpoint.