fix: die from SIGINT when interrupted on POSIX

[mrpmohiburrahman]

Fixes #470.

Pressing ^C made concurrently report success, so set -e scripts carried on, && chains
continued, and cancelled CI steps went green.

The reason it reports 0 isn't that the wrong number is chosen — it's that concurrently ends via
process.exit(), which is a normal termination. A parent sees WIFEXITED and has no way to tell
it apart from a run that was never signalled. 130 isn't a value a process can return; it's what the
shell synthesises when it observes death-by-signal. So no change to the exit code could have fixed
this. @dimikot spelled this out in the issue thread as "method 3", and that's what this implements:
concurrently re-raises SIGINT on itself once the run is over.

You mentioned unix-based systems being the straightforward part, so this is gated on
process.platform !== 'win32' and Windows behaviour is untouched.

What changed. A module-level flag set by a POSIX-only process.once('SIGINT', ...), consumed
inside the existing exitProcess funnel — the one #604 added so restoreCodepage() always runs
first. once matters: the listener detaches itself, so it can't swallow the signal that gets
re-raised. Both the success and failure arms go through it, since a run that fails and gets
interrupted still died of ^C.

The re-raise stays where exitProcess already sits, after result settles. result is the
.finally(...) promise, so teardown commands have already run and KillOnSignal has already
detached its own SIGINT listener — which is what lets the re-raised signal reach the default
disposition rather than being caught again.

kill-on-signal.ts is deliberately untouched. The rewrite of children's SIGINT exit codes to
0 from #164 stays exactly as-is. This is only about concurrently's own status.

On the npm noise that motivated #164. That workaround existed to stop npm 5 printing
ELIFECYCLE on every ^C, so it's fair to ask whether dying by signal brings it back. It doesn't
— measured on npm 10.9.8 / Node 22, sending SIGINT to the process group of a real npm run:

── patched concurrently, interrupted with ^C
npm exit status: 130
> probe@1.0.0 conc
> node .../dist/bin/index.js 'sleep 30'
[0] sleep 30 exited with code SIGINT
ELIFECYCLE occurrences: 0

── control: bare node process killed by SIGINT
npm exit status: 130
ELIFECYCLE occurrences: 0

Zero either way, and npm forwards 130 cleanly — matching what @dimikot predicted would happen.
Modern npm doesn't print the 2018 message for signal death at all, so #164's original rationale
doesn't apply to concurrently's own exit status.

Testing. bin/index.spec.ts already had a test sending a real SIGINT to a real spawned CLI and
asserting exit.code was 0 — it was asserting the bug. Renamed, and re-asserted on { code, signal }
with a platform split, so POSIX expects { code: null, signal: 'SIGINT' } and Windows stays
{ code: 0, signal: null }. I checked it actually guards the fix by reverting bin/index.ts alone
and confirming it fails with the bug's exact signature.

Also verified by hand: ^C now gives 130 where it gave 0; an interrupted run whose command had
already failed also gives 130; and uninterrupted runs are unchanged (0 / 1 / 1 / 0 across success,
failure, mixed and --success first).

• pnpm test — 640 passed (640), same as before the change
• pnpm test:smoke — 4 passed (4)
• pnpm typecheck, pnpm lint, pnpm format — clean
• pnpm build

One judgment call worth flagging: I added a three-line note to docs/cli/success.md, since that
page opens on exit codes mattering in CI and doesn't currently mention that ^C bypasses
--success entirely. Happy to drop it if you'd rather keep the diff to bin/.

[coveralls]

coverage: 98.757%. remained the same — mrpmohiburrahman:fix/sigint-exit-code into open-cli-tools:main