Short-write resume loops in writev code are untested by regular-file tests; interpose writev in the test binary (and cap file size)

Code that batches pieces into writev() and resumes after a short write (advance whole iovecs, then bump iov_base/iov_len of the partial one) almost never sees a short write on a regular file, so the normal test suite doesn't exercise the resume path at all. In a review, deleting the mid-piece resume line broke nothing in the suite, but under a real short write the loop rewrote the same piece prefix forever. The output file reached 6.8 GB in 10 minutes and nearly filled the disk.

A cheap harness: define extern "C" ssize_t writev(int, const struct iovec*, int) in the test executable. Get the real one with dlsym(RTLD_NEXT, "writev") for the uncapped case. When a cap env var is set, write only 1..N bytes per call with plain write() over the iovecs, crossing piece boundaries, and return that count. Run the same workload uncapped and capped (a small cap like 37 to split every header, and a larger one), then check that the files are byte-identical and that the reader's verify passes. One run gave about 28k short writes from about 500 KB of output.

Always run such mutants and probes under ulimit -f and a time limit (Mac bash has no timeout; perl -e 'alarm N; exec @ARGV' works), so a broken resume fails instead of filling the disk. Also check that k == 0 is treated as an error rather than retried, and that zero-length iovecs are skipped both before the first call and after each advance.