No host-side timeout on container wait — one wedged container stalls an entire batch indefinitely

[reacher-z]

There is no host-side deadline on a run.

• src/clawbench/runner/run_support/docker.py:522-585 — docker_wait blocks on [ENGINE, "wait", name] with no timeout.
• src/clawbench/runner/batch.py:313 — await proc.communicate() has no per-job timeout.

The only time limit lives inside the container (runtime/harnesses/base/entrypoint.sh:251, MAX_WAIT=${TIME_LIMIT_S:-1800}). If that watchdog never fires — entrypoint crash, wedged Chromium, container engine hiccup, zombie container — the host waits forever: clawbench-run blocks, and in batch mode the job holds a concurrency slot indefinitely. A 130-task batch can stall overnight with no error and no summary.

Given batches routinely run 8–20 hours (per wall_hours in the leaderboard CSV), a single wedged container is an expensive failure mode.

Ask:

1. Wrap docker_wait in a host-side deadline of time_limit_s + grace (e.g. +5 min), then docker kill the container and classify the run as infra_failure / host_timeout.
2. Wrap proc.communicate() in asyncio.wait_for with the same bound in batch.py, marking the job error: host_timeout so the batch proceeds.

[reacher-z]

@Perry2004 — filed from a read-only audit of main; every claim is cited to file:line and was re-verified by hand before filing. Flagging for your triage: happy to send a PR for any of these you want picked up, or to close it if you judge the behaviour intentional.