fix: Prefer os.Process.Signal to syscall.Kill

[anrddh]

This protects us from a potential (but rare) race condition where

1. the process we are trying to signal terminates of its own accord
2. its PID gets reaped in the os.Process.Wait call
3. a new process with the same PID gets spawned

before our signal actually gets sent.

This is achieved by using the higher-level os.Process API directly, which
has some synchronization to prevent os.Process.Wait and os.Process.Signal
from racing.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarCloud

[F1bonacc1]

Looks great!
Thanks.
How did you manage to catch it?!? 😄

[anrddh]

I've encountered lots of subtle bugs around fork, exec, kill, wait and friends before, so I usually read code that uses them very carefully :)

It's fairly hard to use those syscalls correctly. I've even found discussion for this sort of thing in the Go standard library:
golang/go@cea29c4
golang/go#9382
golang/go#13987