fix(orchestrator): bound destructor collection handoff

[LukeMathWalker]

Why

Destructor fallbacks could create a reaper thread and then call an unbounded Child::wait if thread creation failed. Under resource exhaustion, dropping an orchestration guard could therefore wedge the process indefinitely.

What Changed

• initialize one persistent collector before any managed child is spawned
• transfer destructor-owned children through a non-blocking channel handoff
• multiplex long-lived and short-lived children in the collector worker
• preserve Windows Job Object capabilities while collection is pending
• cover collector multiplexing with a long-lived-child integration test

Risks / Notes

Explicit rollback may still wait while returning a cleanup error; destructor paths only hard-signal and enqueue. If the pre-initialized worker disconnects unexpectedly, Drop deliberately retains the rejected capabilities until process exit rather than blocking or releasing Windows Job authority. Raw fork-without-exec reuse of the library is outside its supported contract. This PR fixes the high-severity review finding on the lifecycle-ownership stack and targets #488.

AI Assistance

Implementation assisted by OpenAI GPT-5.4.