fix(cli): restore the default SIGPIPE disposition

[djbclark]

Follow-up to point 3 of your review on #373.

Rust's runtime ignores SIGPIPE, so a closed output pipe comes back as an
EPIPE write error instead of terminating the process. secretspec then
fails where every other Unix tool exits quietly:

$ secretspec export --format dotenv | head
Error:   × Failed to export secrets
  ├─▶ IO error: Broken pipe (os error 32)
  ╰─▶ Broken pipe (os error 32)
$ echo $?
1

$ secretspec check --json | head
thread 'main' panicked at library/std/src/io/stdio.rs:1166:9:
failed printing to stdout: Broken pipe (os error 32)
$ echo $?
101

check --json is the worse of the two: it panics out of println! rather
than returning an error.

The fix

Reset the disposition to SIG_DFL at the top of the binary entry point. Doing
it there fixes every stdout-writing command at once, instead of teaching each
call site to special-case EPIPE — which is why this is one small commit
rather than three.

After the change, both commands terminate on signal 13 with empty stderr,
and unpiped output is byte-for-byte unchanged.

Tests

secretspec/tests/sigpipe.rs covers both paths: it spawns the real binary,
reads a few bytes, drops the read end, and asserts termination by SIGPIPE
with no stderr. The secret count is sized so output exceeds the ~64KiB pipe
buffer — below that the write fits in the buffer and the pipe never breaks.

I checked both tests fail without the fix, with exactly the errors quoted
above, so they're genuinely pinning the behavior rather than passing
vacuously.

Note on libc

New direct dependency, declared only under [target.'cfg(unix)'.dependencies].
It was already in Cargo.lock transitively, so nothing new is vendored. Happy
to drop it for a hand-rolled extern "C" declaration if you'd rather not add
the direct dep.