DeltaSignal's API is published on all interfaces, unlike every other local service

[adamjohnwright]

Found while auditing the dev box for the nginx migration (#203). Not caused by
that work; it predates it.

What is listening

0.0.0.0:8090     deltasignal-api      ← all interfaces
127.0.0.1:4310   render service       ← loopback only
127.0.0.1:8000   chatbot              ← loopback only

ufw is inactive on this host, and the Docker NAT rule is
0.0.0.0/0 → 8090, not the 127.0.0.1 form the other two use. /api/health
answers 200.

So the only thing standing between DeltaSignal's solver and the internet is the
cloud security group — which I cannot see from the box, and which is not the
layer the other two services rely on.

Why it matters more than an open port usually does

/api/solve runs a perturbation. It is a compute request by design, on a box
whose Tomcat heap already fills within minutes when something walks the pathway
URLs. An open compute endpoint with no authentication is a different proposition
from an open static file.

The fix is one character

~/git/deltasignal/docker-compose.local.yml:

ports:
  - '8090:8080'          # published on every interface
  - '127.0.0.1:8090:8080' # loopback only, matching render and chat

Nothing needs to reach it from outside: the nginx configuration in #221 proxies
/api/ to 127.0.0.1:8090, and the dev server's proxy.conf.js does the same.

Worth checking docker-compose.prod.yml and docker-compose.dev.yml in that
repository too — both publish 8080:8080 on all interfaces.

Note for whoever fixes it

Publishing a container port inserts a rule in Docker's DOCKER iptables chain,
which is evaluated before ufw's rules. So "ufw will catch it" is not true
even when ufw is running. Binding to 127.0.0.1 in the port mapping is the
control that actually holds.