[sandbox audit] Give each pooled sandbox its own capability token

[Wauplin]

[sandbox audit] — PR 4 of 13 in this repo's stack; merge in order.
Previous: #17 · Next: #19
Review only the commits this PR adds on top of its base; bases collapse to main as the stack lands.

Companion client PR: huggingface/huggingface_hub#4832 — deploy this server first.

Why

SBX_TOKEN was one value per server process. In host mode it authorized every route for
every sandbox on the host, plus the pool management routes. So there was nothing narrower to
hand out: the only credential a single sandbox's operator could be given also addressed its
siblings and could delete the pool. The docs called it a per-sandbox token; it was per-job.

That mattered most for proxy_headers, which the client hands to browsers and WebSocket
clients — i.e. the credential most likely to end up somewhere you don't control was the
widest one available.

Approach

Each sandbox gets a random 256-bit token at creation, returned by POST /v1/sandboxes and
recoverable with the host token via GET /v1/sandboxes/{id}/token (so reconnecting to a
sandbox this client didn't create stays stateless — no local state to copy, which is the
property the whole nonce design exists to preserve).

Host-mode authorization now distinguishes two kinds of route:

route	credential
POST/GET/DELETE /v1/sandboxes	host management token
GET /v1/sandboxes/{id}/token	host management token
everything under /v1/sandboxes/{id}/…	that sandbox's token

Token recovery is deliberately management-gated: if a sandbox's own token could read
/v1/sandboxes/<other>/token, the scoping would be trivially bypassable. There is a test for
exactly that.

Also: id and token generation now propagate an error instead of falling back to a timestamp
when /dev/urandom cannot be read. Survivable for an id; for a credential it would mean a
predictable credential, so a failed create is the better outcome.

The compatibility window — read this bit

The host token is still accepted on per-sandbox routes while SBX_COMPAT_HOST_TOKEN=1
(the default). Every job downloads the server binary fresh from a mutable bucket path, so a
hard break would break every client predating this change the moment it is published.

I think that trade is right, and worth being precise about what it does and doesn't leave open:

• Closed now: a sandbox credential can never reach a sibling or the pool. That is the
  finding.
• Still open under compat: a management credential has authority over the sandboxes it
  created — which is what a management credential is for.
• SBX_COMPAT_HOST_TOKEN=0 refuses it today for deployments that want the narrow rule
  immediately, and is tested.

Retiring the default is a follow-up once clients have upgraded.

Validation

• 26 unit tests. A sibling's token is refused; the compat window changes only the host
  token's reach and never makes it classify as a sandbox token; token recovery classifies as
  management; the route→credential mapping is table-driven.

• scripts/token-scope-regression.sh — root container, two sandboxes. Verified to fail
  on the parent commit (9 failures: no token in the create response, no recovery route, no
  scope enforcement) and to pass here, including the SBX_COMPAT_HOST_TOKEN=0 path.

• Driven end-to-end by the real Python client against this binary — the gap the audit
  called out, since the client suite only ever talked to a fake that accepted the host token
  everywhere:

  ok  A's token: exec / files / processes on its own sandbox
  ok  A's token refused for exec, read, write, delete and proxy into B
  ok  A's token refused for create, list, delete-all, and any token recovery
  ok  the host token recovers A's token, and it matches
  

Wire changes

• POST /v1/sandboxes response gains token per sandbox (additive).
• New GET /v1/sandboxes/{id}/token.
• New SBX_COMPAT_HOST_TOKEN env var, documented in the README config table.