Fixes deployment docs to reverse-proxy on a separate Pi, not pi-main

nginx and certbot were designed assuming they lived on the same host
as the app. They don't - a dedicated proxy Pi terminates TLS and
forwards plain HTTP over the LAN. Kestrel now binds 0.0.0.0 instead
of localhost, the whole certbot procedure moved to the proxy Pi's
side, and pi-main gets a firewall rule restricting the backend ports
to just the proxy Pi's address - otherwise binding all interfaces
would let anything on the LAN skip the proxy's TLS entirely.

aidlc-docs/features/gitea-deployment-workflow/construction/u6-deploy-workflow/infrastructure-design/infrastructure-design.md

@@ -17,6 +17,15 @@ That port assignment is a one-time host-setup fact (documented in Operations, FR
 workflow never reads, writes or reasons about a port. Its only environment-specific inputs are the
 deploy path and which systemd unit to restart.
 
+> **Corrected at Deployment Setup, 2026-07-29**: Q10's answer was right that an nginx reverse
+> proxy exists, but wrong about *where* — it runs on a **separate, dedicated Pi**, not on this one.
+> Kestrel therefore binds `0.0.0.0`, not `localhost` (`deployment-instructions.md` § 1.5), and this
+> Pi's firewall must restrict those ports to just the proxy Pi's address
+> (`deployment-instructions.md` § 1.7.1 step 4) — otherwise the proxy's TLS termination is
+> bypassable by anything else on the LAN. The "fixed, pre-configured local port per environment"
+> statement above still holds; only "local" turned out to mean "local to this Pi's network
+> interface," not "loopback."
+
 **Publish target**: `linux-arm64`, **framework-dependent** (Q2 = A, Q5 = B) — assumes the .NET 10
 runtime is already installed on the Pi (ASM-03). Smaller artifact, faster upload over the same SSH
 transport every other unit already relies on.