[5/6][rollout] feat: server admission control, rollout status, and cancel endpoints

[mathewjhan]

Part of splitting #272 into reviewable pieces (5/6). Builds on #286 (backend capabilities).

What this adds

Three server-level behaviors that let a trainer manage load and track rollouts over plain HTTP:

• Admission control on POST /rollout: when the backend's queue is at max_queue_depth, the server answers 429 with a Retry-After header instead of accepting work it cannot start. Accepted rollouts return 202, which states what actually happens: the rollout is queued and runs after the response is sent.
• GET /rollout/{id}/status: reports queued, running, or grading for live rollouts, and success / failure / cancelled (with reward and error message) for recently finished ones, retained for a fixed window. Anything else returns unknown. A trainer polls this as a liveness signal instead of trusting a blind timeout.
• POST /rollout/cancel: takes exactly one selector — {"ids": [...]}, {"prefix": "tenant-a::"}, or {"all": true} — and returns a disposition per rollout (cancelled_queued, cancelled_running, not_found). Prefix cancellation is what a controller uses to stop everything belonging to one adapter when it is deregistered. Cancelling an already-finished rollout returns not_found, so the call is safe to repeat.

Example

curl -X POST $SERVER/rollout -d '{"rollout_id": "tenant-a::r1", ...}'
# -> 202 (or 429 + Retry-After: 5 when the queue is full)

curl $SERVER/rollout/tenant-a::r1/status
# -> {"rollout_id": "tenant-a::r1", "status": "running"}

curl -X POST $SERVER/rollout/cancel -d '{"prefix": "tenant-a::"}'
# -> {"dispositions": {"tenant-a::r1": "cancelled_running"}}