fix(deploy): pass --network=host to podman build (netavark breaks npm sockets)

ROOT CAUSE FOUND. Tested tucker→registry.npmjs.org from the host
directly:

    curl -sS https://registry.npmjs.org/react → 200 in 0.37s, 6.6 MB
    curl -sS https://registry.npmjs.org/@rolldown/binding-...tgz → 200 in 0.37s, 7.8 MB
    10 parallel manifest fetches → all 200 OK

Host network is FINE. The EIDLETIMEOUT failures across 8 consecutive
deploy attempts were happening INSIDE the build container, not on
tucker's network. Podman's rootless netavark networking mangles TCP
keep-alives in a way that breaks npm's HTTP-agent connection pool —
the same registry, same network, same package set, but routed
through netavark, idle-times-out at ~60s with no progress.

Fix: pass `--network=host` to both `podman build` invocations in
scripts/deploy-tucker.sh. Build containers now use the host's
network stack directly (same as how the runtime pushflip pod
already runs `Network=host` per its quadlet) — bypassing netavark
entirely for the install phase.

Why we didn't hit this on the original 5.0.7 deploy: pnpm install's
network behavior is different (different HTTP agent, different
connection lifetimes). pnpm's deadlock surfaced as a libuv-worker
deadlock at ~734 packages. npm's deadlock surfaces as
EIDLETIMEOUT. Different bug, same root cause area (rootless
container networking).

This fix should also let us drop the retry loop (since the
underlying TCP issue is gone), but keeping it as belt-and-suspenders
for now — it costs nothing on success and provides resilience
against transient registry hiccups.

Author: georgedonnelly

scripts/deploy-tucker.sh

@@ -131,8 +131,17 @@ ssh "$REMOTE_HOST" "cd $REMOTE_REPO && git fetch origin main && git checkout mai
 ok "main checked out + workspace installed"
 
 # --- Rebuild images ---
+# `--network=host`: bypass podman's rootless netavark stack during the
+# build. From the host, `curl https://registry.npmjs.org/...` returns
+# 200 in 0.37 s; from inside a default-network rootless container,
+# the same fetch idle-times-out at ~60 s under EIDLETIMEOUT (verified
+# 2026-04-27 after 8 consecutive deploy attempts hit the same
+# pattern). Netavark mangles the TCP keep-alives that npm's HTTP
+# agent relies on. Using host networking for the BUILD only —
+# runtime containers still use the pod's Network=host already.
 step "rebuilding pushflip-vite (~2-15 min depending on lockfile churn)"
 ssh "$REMOTE_HOST" "set -a; source $PROD_ENV; set +a; cd $REMOTE_REPO && podman build \
+  --network=host \
   -t localhost/pushflip-vite:latest \
   --build-arg VITE_FAUCET_URL=/api/faucet \
   --build-arg VITE_NICKNAME_URL=/api/nickname \
@@ -143,7 +152,7 @@ ssh "$REMOTE_HOST" "set -a; source $PROD_ENV; set +a; cd $REMOTE_REPO && podman
 ok "pushflip-vite:latest built"
 
 step "rebuilding pushflip-faucet (~1-3 min)"
-ssh "$REMOTE_HOST" "cd $REMOTE_REPO && podman build -t localhost/pushflip-faucet:latest -f faucet/Dockerfile ." \
+ssh "$REMOTE_HOST" "cd $REMOTE_REPO && podman build --network=host -t localhost/pushflip-faucet:latest -f faucet/Dockerfile ." \
   || { fail "pushflip-faucet build failed"; print_rollback_cmd; exit 1; }
 ok "pushflip-faucet:latest built"