Reap detached command descendants under non-reaping container init #76

A timed-out command with a detached setsid() descendant can leave a zombie when running under a container PID 1 that does not reap adopted children. Killing that descendant stops execution, but waiting only for the direct child does not remove the adopted PID-table entry.

Reported in PR #73 review at 3a198291a29cbb055f819e2a7afdfb10142ce8b4. The existing test_real_timeout_kills_setsid_descendant reproduces the failure when pytest is PID 1 in an isolated Linux PID namespace. The ordinary systemd-hosted test and exact-head CI pass.

This is deferred from the current native systemd deployment, not claimed fixed. Container support without a reaping init needs a separate acceptance gate:

• Reap detached descendants after timeouts and direct-command exit, including TERM-ignoring children.
• Preserve the caller's signal and subreaper state; do not kill or reap unrelated processes.
• Preserve command output, return codes, timeout classification and bounded cleanup time.
• Prove descendant PID entries disappear under both a normal init and a deliberately non-reaping namespace PID 1.

A local command-supervisor candidate and its tests have been preserved for possible future adoption; they are not included in PR #73's selected deployment revision. Do not treat this issue as resolved until that candidate or another repair is independently reviewed and published. Until then, container deployments should use a functioning reaping init.