fix(vpn): PIA OpenVPN on UDP/53 (avoid home WAN:1197 conflict); re-enable vpn-egress

Operator identified the block: the home network NATs its own OpenVPN server on
WAN:1197, colliding with the cluster's outbound PIA-on-1197 flow (port-specific,
not a general UDP block — UDP/53 worked in tcpdump). PIA accepts OpenVPN on
53/1194/1197/1198/8080/9201; chose 53 (empirically proven to traverse this net).

- cluster-vars: add PIA_OPENVPN_PORT="53"
- gluetun: OPENVPN_ENDPOINT_PORT=${PIA_OPENVPN_PORT}
- re-enable vpn-egress; DECISIONS-LOG resolution noted

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

DECISIONS-LOG.md

@@ -507,3 +507,13 @@ filtering; try a wired connection to the main 192.168.1.x LAN; or a different po
 workaround — the user requires non-TCP, and WireGuard (the fallback) is also UDP so likely blocked the same
 way. `vpn-egress` reverted to disabled meanwhile (config is complete + correct; one-line re-enable once the
 network passes OpenVPN UDP).
+
+### Phase 3 VPN — RESOLVED: it was a port-1197 collision, moved to UDP/53 (2026-08-22)
+Operator clarified: the home network already runs **its own OpenVPN server NAT'd on WAN:1197**, which
+collided with the cluster's outbound PIA-on-1197 flow at the router (why UDP/53 worked but 1197 didn't —
+port-specific, not a general UDP block). Fix: set `OPENVPN_ENDPOINT_PORT` to a non-1197 PIA OpenVPN port.
+PIA accepts `53, 1194, 1197, 1198, 8080, 9201` (gluetun issue #2252). Chose **53** — empirically proven to
+traverse this network (the `dig @9.9.9.9` test) and no conflict. Added cluster-var `PIA_OPENVPN_PORT="53"`,
+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.)