vp aborts with SIGABRT when stdout is piped to a reader that exits early (| head)

## Repro (v0.3.1 linux-x64-gnu, also v0.3.0)

```bash
$ vp --version | head -n 1
vp v0.3.1
$ echo ${PIPESTATUS[0]}
134
```

Same with any command that prints, e.g. `vp env list-remote --lts | head`.

## What happens

systemd-coredump records SIGABRT. Strings extracted from the core show the panic message:

```
thread 'main' panicked at library/std/src/io/stdio.rs:1168:9:
failed printing to stdout: Broken pipe (os error 32)
```

Root cause is the classic Rust EPIPE footgun: the runtime ignores SIGPIPE, `println!` panics on the resulting EPIPE error, and the binary is built with `panic=abort`, so a truncated pipe becomes SIGABRT plus a coredump.

## Related

#223 fixed the same panic in a `tokio-runtime-worker` thread, but the main-thread print path is still affected in 0.3.1 — every `vp` subcommand that writes to stdout can hit it.

## Expected

Exit quietly like standard Unix tools: restore SIG_DFL for SIGPIPE at startup (what ripgrep/bat/fd do), or swallow `ErrorKind::BrokenPipe` on stdout writes.

## Impact beyond the crash itself

Each occurrence litters a systemd coredump, and crash-notification tooling that re-runs `vp` to investigate (e.g. an agent running `vp --version | head`) turns one abort into a self-amplifying crash loop — I watched one `vp env list-remote` abort cascade into several more `vp --version` aborts this way.

Inizia dal percorso di avvio di vp e dalla gestione di stdout nel thread principale; riproduci il problema con `vp --version | head -n 1` e `vp env list-remote --lts | head`. Traccia la gestione di SIGPIPE e BrokenPipe, quindi verifica che i comandi con pipe troncate terminino silenziosamente senza SIGABRT o un coredump.

Scritto dal modello di indicizzazione a partire dal testo della issue.