Run OpenBot as one container, and give a Bot a shell

[davidmckayv]

What this changes

Deploying OpenBot meant running four things and a database. It now means running one container.

docker build -t openbot .
docker run -p 3001:3001 --env-file .env \
  -e EMBEDDED_POSTGRES=on -v openbot-data:/var/lib/postgresql/data openbot

The image carries the app, the API that serves it, the browser the Bots drive, and PostgreSQL if you
ask for it. Point DATABASE_URL at a database you already run and the embedded one never starts.
s6 supervises the lot, so a browser that dies takes the container down and lets the platform restart
it rather than leaving an API answering requests it cannot serve. It runs as pwuser, not root.

A Bot gets a shell. computer_run_command runs a command in its /workspace, so it can install
a tool, unpack what it downloaded, or run what it was asked to run instead of only driving a browser.
Through the same gate as everything else: resolve, decide, audit, act. A rule can refuse a shell
outright with intent == "run_command" or refuse particular commands with contains(command, "...").
The command is recorded in full; its output never is, because output is the part that can carry a
page's contents into the audit log. Two minutes by default, ten at most, 64KB kept from the end.

Where a Bot's computer runs becomes a plug. One ComputerProvider interface under the gateway,
with the Docker supervisor as one implementation and a shared computer as another. A computer
somewhere else is an adapter, not a change to the governed path. This is
@mu-hashmi's refactor from #57, which was the right
shape; thank you. The Daytona adapter that came with it is held back and lands separately.

COMPUTER_SANDBOX=on turns on Chromium's own sandbox where the host permits user namespaces.
Playwright re-adds --no-sandbox unless told otherwise, so a deployment that could have had the
sandbox silently did not.

Also: a CHANGELOG.md, written for the person running OpenBot rather than the person who wrote the
commit, and a PR template line asking for an entry.

What driving it found

Three things that only appear when you run the built image rather than read it.

A deployment served over plain HTTP could not start a conversation. crypto.randomUUID is only
defined in a secure context. http://localhost counts as one, so a laptop never sees this; a real
address does not, and the function is simply absent. The chat minted ids with it in five places, all
on the submit path. The throw landed inside a React event handler, was swallowed, and pressing send
did nothing at all: no message, no error, no clue. Found by deploying to EC2 and pressing send.

The first package install failed. The shell runs unprivileged, sudo is there and needs no
password, and nothing told the model, so it ran apt-get install bare and offered to explain how to
do it elsewhere. The tool description now says so.

The audit row for a command said "not in the current snapshot" under what it acted on. A command
has no page element and never will, the same as a file action. It carries the command now.

Where it runs

• New state that outlives a request? None new. The gateway's snapshot cache is unchanged and
  still in process memory, which is why docs/deployment.md says one replica and says why.
• What happens on the second replica? A click resolves element refs against a snapshot the
  other replica took and fails to find them. This image is the single-box shape on purpose; the
  fleet shape is A6.
• Anything serialised? Nothing new. Migrations run at start only with EMBEDDED_POSTGRES=on,
  where there is exactly one process; with an external database they stay a release step.
• Anything fanned out to a browser? Nothing new.
• New listener, port, or schedule? One port, 3001. The browser listens on 4100 inside the
  container and is deliberately not published.

Boundary and audit

• computer_run_command goes through the gateway like every other acting call: resolve, decide,
  audit, then act.
• A refused command writes a row and never reaches the computer.
• Command text comes from the model and is recorded; output is not, and is never trusted.

Changelog

• CHANGELOG.md, under Unreleased. This PR also introduces the file.

Proof

Driven in Chrome against the built image, twice: locally, and on a fresh EC2 box (Ubuntu 24.04,
amd64, built from source on the host so the Dockerfile is proven on a clean machine and an
architecture other than my Mac).

Browser	opened example.com, screenshot rendered in the channel
Shell	sudo apt-get update && sudo apt-get install -y jq, then jq --version → jq-1.7, first try
User	runs as pwuser, /workspace owned by it
Database	embedded PostgreSQL, vector created, migrations applied at start
Audit	both commands recorded verbatim, no output in the row
Boundary	contains(command, "uname") → Blocked, named the rule, never reached the computer

744 tests pass, typecheck and format clean.