Child stderr fidelity: default SIGPIPE on exec, opt-out for the txn stderr tee

[congwang-mk]

Summary

Two child/stage stderr behavior fixes, split out of #172.

1. Sandboxed programs inherited an ignored SIGPIPE

The Rust runtime ignores SIGPIPE process-wide and an ignored disposition survives execve, so every program exec'd by sandlock's own fork/exec path started with SIGPIPE ignored: writes to a closed pipe returned EPIPE and utilities printed 'Broken pipe' errors instead of dying silently the way they do under a shell. Beyond the noise, exit statuses changed shape (EPIPE error exit instead of death by signal 13), sandlock's pipeline stages saw EPIPE instead of clean SIGPIPE death when a downstream stage exited early, and child behavior silently depended on which language the embedding process was written in (CPython also ignores SIGPIPE; a C embedder does not).

Fix: reset SIGPIPE to SIG_DFL in the child right before execvp, matching what std::process::Command, posix_spawn, and shells do. The in-process entry arm is untouched: it runs Rust code that expects the Rust runtime's disposition.

2. Transaction stages tee stderr to the parent's fd 2 with no way to opt out

The live tee is right for the interactive CLI but wrong for embedders whose fd 2 is not the place for workload output, and for test harnesses (raw fd writes bypass libtest's capture, so the stderr-cap test sprayed its 128 KiB flood payload onto the terminal).

Fix: add Transaction::tee_stderr(bool), default true so the CLI keeps its behavior, threaded to the tee open in the stage driver; stages become capture-only when disabled. The stderr-emitting transaction tests opt out, keeping the suite's terminal output clean.

Test plan

• x86_64: sandlock-core lib (675), transaction integration tests (42, quiet output verified), sandlock-ffi popen suite (9, no more 'Broken pipe' spam), full sandlock-cli and Python (386) suites passed on the combined branch before the split

🤖 Generated with Claude Code

[congwang-mk]

@dzerik This is probably introduced by your recent pipline transaction changes. Please take a look.