fix(hooks): let a hook that ignores its stdin succeed

[umars28]

The bug

one() writes the container state to the hook's stdin and propagates the error:

.write_all(payload)
.ctx("write the container state to the hook's stdin")?;

A hook that exits without reading closes the read end first, so the write returns
EPIPE and the hook is reported as failed — even though it exited 0.

Why it is a race, not a constant failure

The payload usually fits in the pipe buffer, so the write completes before the
child is reaped and nothing looks wrong. A larger payload, or a loaded machine,
loses that race.

It showed up as a_hook_that_succeeds_is_not_an_error failing in CI on
#5, a change that
touched no Rust at all, and then passing on a re-run with nothing altered. It
passed 20 out of 20 runs locally, which is consistent with the diagnosis rather
than against it.

Why the current behaviour is wrong

The runtime-spec writes the state to the hook's stdin but makes the exit code
the verdict. A hook may ignore what it is handed, and most real ones do: they run
a command and never read anything. mars refuses those hooks non-deterministically,
more often on the busy machines where hooks matter most.

The change

BrokenPipe on that write is no longer fatal; the exit status decides, as it
already did. Every other write error still fails, and now kills the child instead
of leaving it running.

The test

a_hook_that_never_reads_its_stdin_is_not_an_error hands /bin/true a megabyte,
which cannot fit in the pipe buffer, so the write always outlives the child. It
does not depend on timing, and it fails deterministically without this change:

called `Result::unwrap()` on an `Err` value: Io {
  context: "write the container state to the hook's stdin",
  source: Os { code: 32, kind: BrokenPipe, message: "Broken pipe" } }

cargo fmt --check, cargo clippy --all-targets -- -D warnings and
cargo test --lib (107 passed) are green.