fix(plugins): make SIGKILL escalation idempotent per child

[anhtahaylove]

loadPlugin() attached a new child.once("exit", () => clearTimeout(killTimer)) on every SIGTERM→SIGKILL escalation. once only detaches when exit actually fires, so a plugin that traps SIGTERM keeps serving calls and accumulates one listener plus one killTimer closure per hook timeout. Node prints MaxListenersExceededWarning once eleven pile up. Healthy plugins never reach this path.

The change

Escalation is now guarded by a WeakSet keyed on the child, so a child already being killed does not re-arm. That is also all that is useful: SIGKILL cannot be ignored, so a second timer would only re-signal a corpse. Both the timer and the listener are released on every path — including the one where the child never exits, which once alone does not cover.

The shared helper also replaces two copies of the same block (hook-timeout path and cleanup()).

Note on the first attempt

Self-detaching the listener inside onExit is not sufficient on its own, and the test caught it. The grace period is 3s, far longer than the interval between hook timeouts, so listeners still accumulated faster than they were released:

AssertionError: hook timeouts must not accumulate exit listeners (#12819):
  Possible EventEmitter memory leak detected. 11 exit listeners added to [ChildProcess].

Idempotence per child is what actually fixes it.

Test

tests/unit/plugins-sigkill-listener-leak-12819.test.ts loads a real plugin that traps SIGTERM and never answers a hook, then drives 12 timeouts. It observes the leak the way a user does — by listening for Node's own MaxListenersExceededWarning — because the child handle is private to the loader; asserting on a handle the test cannot reach would have silently passed either way.

Verification

plugins-sigkill-listener-leak-12819 + plugins-loader + plugins-loader-ipc   14 passed
npx tsc -p tsconfig.typecheck-core.json --noEmit    clean
npx eslint <changed files>                           clean

Fixes #12819

[anhtahaylove]

Note on the checks here: the workflows are sitting in action_required because this is my first PR to this repo, so GitHub holds them for maintainer approval. The three green checks shown (Mergify, semgrep) are the ones that run without it — the test and typecheck jobs have not run yet. Approving the workflow run will give you the real signal.

Locally on Windows 11 / Node 24.19.0: tsc -p tsconfig.typecheck-core.json --noEmit and eslint are clean on the changed files, and the touched suites pass. The 5 failures in the full tests/unit/compression/** run are pre-existing RTK cases that reproduce on a clean release/v3.8.51 checkout with my changes stashed.