Do not start a container this supervisor does not own

[beardthelion]

Closes #102.

ensure treats a 409 from createContainer as the other request creating the same computer and goes on to start the container by name. That is right when the container already there is ours and wrong otherwise: a container left by a deployment under a different namespace, or made by hand, gets started and handed back as this Bot's computer, and its address is where COMPUTER_TOKEN goes next.

The file's own header says a name that lacks the label is treated as absent. This was the one path that adopted it instead.

What it does

• A 409 is followed by the same inspectOwned check the rest of the module uses. Ours, and the request carries on as before, which is what keeps ensure idempotent under concurrent calls for one Bot. Not ours, and it is refused with NameHeldError and left alone, stopped.
• NameHeldError is its own class, answered as 409 rather than 503. The daemon is fine, and an operator sent to look at Docker would find nothing; what has to happen is that somebody looks at the container holding the name.
• waitUntilAnswering throws instead of returning at its deadline, as ComputerNotAnsweringError, answered as 503 because the caller's next move is still to wait and ask again. A wait that cannot fail is a sleep, and it was reporting every computer that never came up as ready.
• The readiness timeout is now an EnsureOptions field. It decides when a slow start becomes an error rather than when a log line appears, so a deployment pulling a large image on a cold host should be able to say so.

Verification

Reproduced against a real daemon before the change: a container named openbot-computer-<bot> carrying someone.else=true was started by ensure and returned as the computer with status: unknown. After: refused, and docker inspect shows it still created.

supervisor/tests/docker.integration.test.ts covers three cases against a real socket:

• the foreign container is refused and never started, asserted on the daemon's own view of it rather than on the thrown error alone
• a container this supervisor owns is still started, which is the case a check written as "does the name exist" would break
• an owned container that never reports healthy fails instead of being handed out

Both halves reverted with the tests live to confirm they fail.

The tests skip where the socket is not reachable, which is most CI. A stub cannot show any of this: the behaviour under test is the daemon's 409, not ours, and a fake would be asserting about itself. bun test supervisor/tests runs 11 with 3 skipped where there is no socket, 3 passing where there is.

bunx tsc --noEmit and bunx biome check clean. Whole-tree failure set identical to main.

One interaction

ensure now has a failure mode it did not have, so a deployment whose computer takes longer than 60s to answer gets a 503 where it previously got a "ready" it could not use. That is the intended direction, and readyTimeoutMs is there for the deployment that needs longer.