File writes do not terminate on zero progress #1445

Nonempty file writes can spin indefinitely after a zero-byte host write

On current main 8578b7cbf2a7944218b750dcb62bd917babe5994, both File.write and File.write_bytes use loops that advance only by the returned byte count:

• C: bend2/effs/file_write.c, file_write_call: the loop permits n >= 0, so write(..., remaining) == 0 leaves at unchanged.
• JS: bend2/effs/file_write.js, file_write_buffer: at += fs.writeSync(...) likewise has no zero-progress exit.

A descriptor-scoped fault-injection fixture opens a real temporary file, allows a real seven-byte short write, then makes the next nonempty host write return zero. The other descriptors, including stdout/stderr, are unaffected. With a one-off zero return, all three tested consumers (native C, Bun CLI, and emitted standalone JS under Node) retry and incorrectly report success. With subsequent writes kept at zero, all three exceed an explicit two-second deadline (exit 124).

This is an injected host-return edge case, not a claim that a normal disk spontaneously produced it. The unchanged positive writes go through the real filesystem.

Expected behavior

For a nonempty remaining buffer, stop on zero progress and return EIO (5), retaining the File handle outside the Result. Already-written bytes must remain available, and the caller must be able to recover using the returned handle. Empty text/byte writes should still succeed. Positive short writes should still be completed. Existing negative-error behavior should remain unchanged.

The incoming regression fixture exercises binary bytes (including NUL and values above 127), UTF-8 text, empty writes, the actual written prefix, and recovery with the returned handle. I will link the ready fix and executable reproduction here once published. No syscall retry policy, compiler budget, or gate changes are needed.