drop-sudo treats signal-terminated helper commands as successful

Summary

The internal execCommand() helper in src/dropSudo.ts normalizes a signal-terminated child to exit code 0:

child.on("close", (code) => {
  const exitCode = code ?? 0;

Node reports code === null and supplies the terminating signal separately when a child exits because of a signal. As a result, a required drop-sudo helper command can be terminated and still resolve as successful when ignoreFailure is false.

Reproduction / evidence

Current main is 86365089eb2b84e0a8fb0717b304f8bdcb13b20e.

The underlying Node behavior is deterministic:

const { spawn } = require("node:child_process");
const child = spawn(process.execPath, ["-e", "setInterval(() => {}, 1000)"]);
child.on("close", (code, signal) => {
  console.log({ code, signal, normalized: code ?? 0 });
});
setTimeout(() => child.kill("SIGTERM"), 20);

Output:

{ code: null, signal: 'SIGTERM', normalized: 0 }

Expected behavior

A command terminated by a signal must reject when failure is not explicitly ignored. The error should retain the signal so the diagnostic is distinguishable from an ordinary numeric exit.

Suggested fix

Handle the close signal argument explicitly and treat code === null as failure. Add a focused mocked-child regression for a close(null, "SIGTERM") event, plus a control for ordinary exit code 0.

Impact

This is privilege-transition correctness. execCommand() is used for required account, group, sudo, and verification operations. Later checks catch some incomplete transitions, but the helper itself currently converts an interrupted required operation into success and can let execution continue with misleading state.

Start in src/dropSudo.ts at execCommand() and read how the child process close event resolves or rejects. Reproduce the mocked close(null, "SIGTERM") case and compare it with ordinary exit code 0. Done means required signal-terminated commands fail with their signal available for diagnostics, while successful commands still resolve.