* Bound per-evaluation sandbox disk use

A sandbox writes its output to a host-backed directory, so a single file
or a flood of files could otherwise consume host storage without limit.

- Give the sandbox a hard per-file write ceiling (--ulimit fsize), matching
  the 512 MiB output read cap.
- While the sandbox runs, the validator checks the bytes and file count the
  sandbox user has written to the evaluation directory, and kills the run
  and fails that evaluation if either passes its budget. Only the sandbox
  user's files count, and sparse files count only their allocated blocks.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

* Measure disk use by free space, not a name walk

A name-based walk of the evaluation directory misses disk a run consumes
through files it unlinks while still writing, directory floods, and
special files. Measure the filesystem's free space and free inodes
against a baseline instead (a single statvfs, cheap enough to poll every
loop), and check once more after the run. This catches those paths and
is simpler. Budget the bytes above the validator's own capped capture
logs written during the run.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

* Derive the per-file cap from the output read cap; tidy tests

Use MAX_SANDBOX_OUTPUT_BYTES for the fsize ulimit so the write ceiling
can't drift from the size the validator rejects on read, and drop an
unused variable in the budget test.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

* Keep the disk guard from raising inside the poll loop

A statvfs error must not propagate out of the guard: run_capped calls it
in the wait loop, where an exception would skip killing the child and
could wedge the reader-thread join. On a measurement error the guard now
returns no verdict instead.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

---------

Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>