stack_upgrade reasserts the Tor-egress firewall AFTER compose up — same startup window #276 fixed for `up`

[VijitSingh97]

What

#272 added apply_tor_egress_firewall to stack_upgrade after compose_up_checked -d --build. #276 had moved it before compose in stack_up precisely to avoid a startup window where a clearnet app (Tari, #271's firewall-blocked residual) opens connections that the leading ESTABLISHED rule then grandfathers past the DROP. The upgrade path still has that window.

When it bites

Only when the firewall is not already installed as pithead upgrade runs — e.g. pithead down then pithead upgrade (instead of up). In normal operation the firewall is installed at up and persists across upgrade (Docker never flushes DOCKER-USER), so there's no window. Low severity.

Observed

Deploying develop to gouda's canonical (down the old stack → git checkout develop → pithead upgrade), Tari came up holding 2 grandfathered public peers (57.129.110.6, 78.80.36.112); a docker compose restart tari cleared them (re-dialed under the now-present firewall + proxy_bypass=false → all-Tor [verify-egress] OK).

Fix

Move apply_tor_egress_firewall to before compose_up_checked in stack_upgrade (after the .env render so the toggle/subnet are available), matching stack_up (#276). 1-line consistency fix; add a regression note.

Refs #270 #272 #276.