fix(caddy): *arr stack and qBittorrent are LAN-only at the edge

A missing Porkbun record was never the gate: Caddy issues one certificate per
name and every one is in public CT logs, so the *arr hostnames were discoverable
and the edge accepted them. Each of the five vhosts now carries a remote_ip
source gate (LAN proxies through, everything else gets 404) - the posture the
Sonarr comment already claimed. AGENTS.md records the LAN-gate shape as the
required form of internal-only, and Caddy.md records why DNS secrecy is fiction.

AGENTS.md

@@ -231,7 +231,17 @@ Every Caddy-proxied service is in exactly one of three postures: behind the
 auth chain (Anubis :8923 → Authentik embedded outpost), **exempt by
 construction** because it authenticates itself (`auth.`, git smart-HTTP, Gitea,
 OpenWebUI, Jellyfin, Plex, Audiobookshelf, the *arr stack), or internal-only —
-no public DNS name, no vhost. New services default to internal-only until guarded.
+served to nobody off-LAN. New services default to internal-only until guarded.
+
+**Internal-only is a source gate, not a missing DNS record.** Caddy answers
+every Host it knows, and its per-name certificates are published in Certificate
+Transparency logs, so a name with no Porkbun A record is still in a stranger's
+reach (`crt.sh` lists it). A household-only service therefore carries an edge
+gate — `@lan remote_ip 127.0.0.1/32 ::1/128 192.168.0.0/16 10.0.0.0/8
+172.16.0.0/12`, `handle @lan { reverse_proxy … }`, `handle { respond 404 }` —
+which is what the *arr stack and qBittorrent carry (2026-11-04: Frank's law,
+"never leaving the home boxes"). A future household-only vhost gets the same
+block, not merely an absent record.
 
 The guard chain is a **browser-only device**: Anubis demands a JavaScript
 proof-of-work and the outpost works from a session cookie, so any non-browser