Rebuild a Bot's computer when it holds a token the deployment no longer uses

[davidmckayv]

Found by doing the thing nobody had done: a from-zero install of the desktop app on a Mac,
against the published v0.0.9, with the credential store emptied first.

Every page the Bot tried to open failed, and so did the live screen. What the trail said:

{ "bot": "picked-harness", "page": "https://news.ycombinator.com/",
  "action": "computer_navigate", "failure": "Not authorised.",
  "decision": { "mode": "enforce", "rule": "true", "source": "allow",
                "allowed": true, "carriedOut": true } }

The gateway allowed it. The computer refused it. Nothing on screen named a cause.

Why. A computer checks callers against the COMPUTER_TOKEN it was created with and holds that
one for the life of the container. The shell mints the generated secrets once per deployment and
deliberately does not rotate them, because a computer outliving a restart is what rotating would
strand. But a machine set up again from nothing does mint a new token: compose rebuilds everything
it owns with it, and the computers are the one thing compose does not own, because the supervisor
makes them. On this machine the surviving containers were from installs five days and one hour
earlier, still holding their own tokens:

openbot-computer-picked-harness    created 10:02   token sha d2a02a03...
openbot-supervisor-1               created 17:36   token sha 022f1e97...
openbot-agent-computer-1           created 17:36   token sha 022f1e97...

The fix. ensure already replaces a computer built from an older image, for the same class of
reason: the supervisor makes these, so nothing else reaches them. It now also replaces one whose
token is not the one being handed out. The profile and workspace volumes are kept, so the Bot comes
back with its logins and its files, exactly as on the image path. A deployment that sets no token is
left alone, because a computer with no door on it is a choice the environment made rather than a
mismatch to act on.

Tests. Two cases in the Docker lifecycle fixture, against a real daemon: replaced when the token
has changed, left alone when it has not, including when the new environment names no token at all.
The fixture's case count and the assertion guarding it go from five to seven. Checked by disabling
the comparison, at which point the replacement case reuses the old container and fails.