fix: exit on EPIPE instead of infinite uncaughtException loop and unbounded spawn - #960

Fix bugs

Bug detail

When a command error occurs while stdout is connected to a pipe whose reader exits early (e.g. s info -t s.yaml 2>&1 | head -5), the CLI enters a never-ending error-handling loop and piles up node processes:

1. Any error (e.g. ${env('X')} referencing an unset environment variable in s.yaml) is reported by handleError, which writes the error message to stdout and spawns a report.js telemetry daemon (src/exec-daemon.ts).
2. Once the pipe reader (e.g. head) has exited, every further write to stdout fails with EPIPE, which surfaces as an uncaughtException.
3. uncaughtException → handleError → writes to stdout again + spawns another daemon → EPIPE → …

Each cycle spawns one detached node child (lib/daemon/report.js, alive ~30s), so the process table fills up until the system pid limit. The CLI process itself never exits on its own; repeated EPIPE records also grow the log file without bound (~16 cycles/s on Linux, much faster on macOS).

Reproduced in a resource-limited container (node:22, --pids-limit, no network) with timeout 15s as watchdog:

Fix (standard Unix SIGPIPE semantics — when the pipe reader is gone, exit instead of writing again):

• register error listeners on process.stdout / process.stderr that exit on EPIPE (src/index.ts);
• short-circuit EPIPE in the uncaughtException handler instead of re-entering the error-handling flow.

Pull request tasks

• Add test cases for the changes
• Passed the CI test

Regression test in __tests__/error.test.ts: pipes the CLI output to an early-exiting reader. Before the fix the spawnSync call is killed by its timeout (the pipeline never exits, ETIMEDOUT); with the fix it finishes in ~200 ms.