Whether pid is safe to hand to a negated process.kill.

This guard is the whole reason this module is not a one-liner. process.kill(-pid) is the POSIX "signal the whole group" form, and two pid values turn it into something catastrophically broader:

• 0 negates to 0, and kill(0, …) signals every process in the caller's own group — for a CLI run from a terminal, that is the shell and everything sharing its job.
• 1 negates to -1, and kill(-1, …) signals every process the user is permitted to signal. On a desktop session that is the session: it logs the user out.

Neither is hypothetical from a caller's point of view — pid arrives from ChildProcess.pid (typed number | undefined), from parseInt over a /proc entry, and from a pid parsed out of a file on disk. Any of those can produce a value the caller believed was a real child's. And because the kill itself is deliberately error-swallowing, a wrong pid leaves no trace at all.

So the check lives here, at the primitive, rather than being re-derived at each call site: a group kill is only ever attempted for a pid that could actually be a spawned child.

isTargetablePid(4242); // true
isTargetablePid(1); // false — negates to kill(-1), every process the user owns
isTargetablePid(0); // false — negates to kill(0), the caller's own process group
isTargetablePid(Number.NaN); // false