fix(vpn): PIA OpenVPN port 53 -> 8080 (53 is DNS-intercepted on this network)

Port 53 also got no PIA replies: this network transparently intercepts outbound
:53, so dig works but OpenVPN-over-53 is swallowed. An NTP/123 probe from the host
returned fine, proving arbitrary non-53 UDP works bidirectionally (so it's
port-specific: 1197 conflict + 53 DNS-intercept, not a UDP block). Move to 8080
(community-verified for PIA, non-DNS, non-1197).

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

DECISIONS-LOG.md

@@ -517,3 +517,11 @@ traverse this network (the `dig @9.9.9.9` test) and no conflict. Added cluster-v
 wired to gluetun `OPENVPN_ENDPOINT_PORT`, and re-enabled `vpn-egress`. Port-forwarding is an over-tunnel PIA
 API call, unaffected by the transport port. (WireGuard fallback would also have worked — PIA WG is UDP/1337,
 not 1197 — but staying on Gluetun+OpenVPN is the smaller change.)
+
+**Correction: 53 didn't work either → settled on 8080.** Deploying on 53 still got no PIA replies —
+this network **transparently intercepts outbound :53 (DNS)**, so `dig` succeeds (proxy forwards it) but
+OpenVPN-over-53 is swallowed. Cheap decisive test: a raw **NTP/123** probe from the host got a reply →
+arbitrary non-53 UDP works bidirectionally, so it's port-specific (1197 conflict + 53 DNS-intercept), not a
+UDP block. Moved `OPENVPN_ENDPOINT_PORT` to **8080** (community-verified for PIA, non-DNS, non-1197).
+Also hit the `${VAR}`→int-coercion gotcha (k8s "expected string, got 53") — the port is hardcoded as a
+quoted string in gluetun-gateway.yaml (Longhorn-fix precedent), not a cluster-var.