[sandbox audit] Bound server resources, and fix two file-protocol bugs

[Wauplin]

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

Why

A pool host has no cgroups to partition its sandboxes, so anything one sandbox can consume
without limit, it takes from its neighbours. Several of those limits were missing — and two
file-protocol bugs corrupted data rather than merely wasting memory.

The two data bugs

A shrinking file desynchronised the connection. A read advertised Content-Length from
the file's size, then stopped early if the file shrank mid-transfer — and kept the keep-alive
connection open. The next response then began mid-body and was read as the tail of this one.

A ranged write left a stale tail. Ranged writes deliberately don't truncate, so
overwriting a large file with a smaller one through parallel chunks left the old bytes past
the new end. (This is also what clippy's file opened with create, but truncate behavior not defined was pointing at.)

The bounds

• max_procs / max_mem_mb came straight from the request body, and max_mem_mb * 1024 * 1024 had no checked_mul — a value near 2^54 wrapped in release builds, producing either
  an effectively unlimited address space or a sandbox where nothing can start.
• Only RLIMIT_NPROC and RLIMIT_AS were set — nothing stopped one sandbox exhausting
  the host's descriptors, filling its disk, or spinning a core.
• The output channel was unbounded: a client that stopped reading a 50 MiB producer took
  server RSS to ~52 MiB, per connection.
• Invalid numeric config fell back to a default — for SBX_CAPACITY that meant an
  unlimited host, so a typo silently removed the packing bound.

Behaviour change worth naming

Bounding the output queue means a stalled client now slows the command rather than growing
the server's heap. That's how docker logs behaves and the right trade on a shared host, but
it is a real change: a command producing faster than its consumer reads will block. The buffer
is ~2 MiB, comfortably more than any interactive command produces between reads.

SBX_CAPACITY also now defaults to 64 rather than unlimited. Unlimited was the absence of
a setting, never a considered choice, and the client always sets it explicitly.

Also

count is bounded by the host's remaining capacity rather than an arbitrary 4096 (the env map
is cloned per sandbox); the create env is capped at 64 KiB; directory listings are paginated
(limit/after, reporting truncated/next); and a non-regular file is refused in dedicated
mode too, so a FIFO can't block a connection thread waiting for a writer.

Validation

scripts/resource-bounds-regression.sh, all passing:

refused SBX_CAPACITY=abc / SBX_PORT=notaport / SBX_MAX_CONNECTIONS=-5 / SBX_CAPACITY=0
max_mem_mb 2^54, u64::MAX, 0 and max_procs 0, 100000 -> 400; a sane request -> 200
count: 4000 on a capacity-4 host -> created 3, rest reported rejected
200 KB env -> 400
ulimit -n inside a sandbox -> 4096
ranged overwrite -> file is exactly what was uploaded, no stale tail
listing: limit honoured, truncation reported, cursor advances (not repeating)
FIFO -> refused promptly (400), not a hang
stalled reader: RSS 648 kB before, 648 kB after 64 MiB of unread output
5 MB round-trip + streamed exec still work

Verified against the parent commit: every invalid config accepted, every out-of-range
limit accepted, the 200 KB env accepted, no pagination.

Two of my own test bugs along the way: a 200 KB env on the command line exceeds ARG_MAX, and
I set SBX_PORT twice in one env invocation so the valid value won — the check passed
against a server that had ignored the bad value entirely.

Wire changes

• PUT /v1/files/write gains truncate_to.
• GET /v1/files/list gains limit/after and returns truncated/next (additive).
• A read of a file that shrinks mid-transfer now closes the connection instead of returning
  short and reusing it.

The client-side half of this finding (full output capture even with callbacks, read_bytes()
uploads, fully-materialised parallel downloads) is a separate PR.