Restart the tunnel services after the hub they live inside

Both VPN services share the provisioning container's network namespace, and a
process holds the namespace it started in. Restarting the hub — which every
deploy does, to pick up new code — therefore leaves them listening inside a
namespace that no longer exists.

Nothing errors. The containers stay up, Caddy's log still reports it is serving
on the tunnel address, and connections to that address are simply refused. It
looks precisely like a gateway that never worked, which is how it presented on
the live server after the first successful start.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

deploy/update.sh

@@ -316,6 +316,15 @@ docker compose up -d
 # keep running the code from before the update.
 docker compose restart queue queue-provisioning scheduler reverb
 
+# AFTER the hub, always. Both VPN services live in the provisioning container's
+# network namespace, and a process holds the namespace it started in — so once
+# the hub is restarted they are listening inside one that no longer exists.
+# Nothing errors; connections to the tunnel address are simply refused, which
+# looks exactly like the gateway never having worked.
+if grep -qE '^COMPOSE_PROFILES=.*vpn' .env 2>/dev/null; then
+    docker compose --profile vpn restart vpn-dns vpn-gateway >/dev/null 2>&1 || true
+fi
+
 reconcile_vpn_readiness
 
 log "Leaving maintenance mode"