Open what is shut, and never widen what is already open

setup-server queried --query-port, saw "not open", and blanket-opened 80,
443 and 81. On a machine reaching those ports through rich rules -- one CDN's
address sets, say -- neither appears in --list-ports, so the step read a
deliberate, narrow grant as "closed" and replaced it with a public one. It
did this during `panama update`, which asks nothing and runs unattended, so
there was no prompt and no diff for anyone to read. A production server lost
its firewall posture that way, port 81 and the proxy's admin portal included.

Each port is now checked for existing coverage first -- an open port, an
enabled service, or an accepting rich rule, ranges included -- and left alone
when it has some. The bias stays where it was: only a rule that positively
reads as a grant counts, and anything unrecognised still falls through to
opening the port, because a fresh server that is silently unreachable is the
worse failure. A rule that DROPS a port is not coverage either; reading a
block as a grant would leave the proxy unreachable on a machine nobody
thought to re-check.

A machine that manages its own firewall opts out once, with
`echo manual > ~/.local/state/panama/firewall`, and Panama never touches
firewalld on it again. A file rather than an environment variable, because
the run that needs to respect it is the unattended one.

tests/setup/server-firewall-contract pins all of it, and fails against the
previous code on exactly the cases that cost the posture.

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>

server/README.md

@@ -40,7 +40,13 @@ is what `panama server enable` refuses to start on.
   the volume path they were running with until their cutover, because the
   repo copy must render identically to the live one — renames happen with
   the service stopped, not in git.
-- Only 80, 443 and 81 are open (setup-server's doing). Everything else is
+- Only 80, 443 and 81 are open, and `setup-server` opens each one only where
+  nothing already grants it. A port reachable through an enabled service or an
+  accepting rich rule — a CDN-scoped grant, say — is left exactly as it is,
+  because turning a narrow grant into a public one during an unattended
+  `panama update` is not a decision an installer gets to make. A machine that
+  manages its own firewall opts out for good with
+  `echo manual > ~/.local/state/panama/firewall`. Everything else is
   reverse-proxied over the `nginx-bridge` network by container name, with no
   published ports of its own. A service that truly needs another host port
   says so in a README in its directory, and the port is opened by hand.