fix(runner): release both teardowns when Ctrl-C stops a parallel run

[Chemaclass]

🤔 Background

Related #1331

Under --parallel, Ctrl-C released neither the per-test tear_down nor the file's tear_down_after_script. The parent's kill takes the file worker down outright, and since #1320 that worker is the only frame holding the file's hook.

💡 Changes

• The worker handles the signal itself and settles the teardown debt the parent recorded before dispatch. The debt is cleared before the hook runs, so a signal landing mid-teardown cannot release the same resource twice.
• Each test gets its own process group, and the handler signals the group. A per-pid signal is not enough: bash defers a trap until the running command returns, so a body sitting in the test's own sleep never reaches the EXIT trap where tear_down lives.
• TERM only. A terminal does deliver Ctrl-C's INT to the whole foreground group, worker included, but the worker never sees it: a shell sets SIGINT to SIG_IGN in a job it backgrounds, and a signal ignored on entry can be neither trapped nor reset. Measured the same on bash 3.2 and 5.3. Cleanup reaches this frame as the SIGTERM the parent sends, so the issue's note asking for INT as well cannot be honoured and does not need to be.
• Two other corrections to the issue's model: the test body is a great-grandchild of the runner, not a grandchild, and no pkill -P $$ sweep is possible in the worker, because $$ names the runner inside a subshell and the sweep killed the handler itself.
• Known limit, measured: a file opting out of per-test parallelism runs its bodies unforked, so the worker sits in a command substitution and defers the trap. Both hooks still run for such a file, when the body finishes rather than when the signal lands. Nothing is leaked; the interrupt just does not cut that test short.
• Unit-tested rather than signal-tested, as the issue prescribes: a real delivery depends on which frame the shell is in and flaked 2 runs in 3 for Ctrl-C does not run tear_down_after_script for the file in flight #1323. Interrupt behaviour was verified by hand on bash 3.2 and bash 5.3, against a main baseline.