Keep the database off the network a Bot's shell is on (#218)

* Keep the database off the network a Bot's shell is on

Compose declared no networks at all, so every service joined one and reached the
others by service name. One of those services is agent-computer, which is where
a Bot's shell runs, and another is postgres, whose username and password are
three lines above it in the same file.

So a Bot could open postgres:5432 and authenticate. That is the audit trail, the
policy store and the agent tables, from the one container whose whole job is to
run what a Bot was asked to do, driven by an operator or by content on a page the
Bot was told to read. shell.ts already says what this breaks: isolation is the
container's job, a shell can reach whatever the container can reach.

The role Compose creates is the instance owner, so the append-only trail was not
a defence against this either. The trigger refuses a delete and its owner can
drop the trigger.

postgres and migrate, the only service that reaches it by name, now have a data
network to themselves. Nothing else moves, so the supervisor, SPIRE and the two
Bots keep every relationship they had, and a server on the host is unaffected
because it reaches the database through the published port rather than the
shared network.

The per-Bot path already did this correctly, which is what made the gap look
like an omission: with COMPUTER_NETWORK unset the supervisor gives each computer
no NetworkMode, so it lands on the default bridge away from Compose, with
CapDrop ALL and no-new-privileges besides.

* Note the network split in the changelog

Says what an operator has to do if they run the server inside Compose, and that
a deployment which has been running this way should look at its trail rather
than assume the change is retroactive.

* Publish the database on loopback, like every other port in the file

Taking postgres off the Bots' network removes the name and leaves the
address. A container's default gateway is the host, and a port published
on every interface answers there: from inside agent-computer, the gateway
on 5432 accepted a connection and began authenticating as openbot on
openbot, with the password three lines above it in this file. So the
reachability this change is about survived it.

Every other port here is already bound to 127.0.0.1 with a comment saying
why. Driven both ways: the name and the gateway are now both unreachable
from the computer container, the container still reaches the internet,
migrate still exits 0 across the network split, and the server on the
host still connects.

---------

Co-authored-by: David McKay <davidmckayv@users.noreply.github.com>