[ML] PR D: linear child ownership and fault-injected lifecycle for Sandbox2

[valeriy42]

Summary

Rebuilds CSandboxedProcessSpawner around an explicit lifecycle state machine (Prepared -> Launched -> IdentityCaptured -> Registered -> Monitoring -> TerminationRequested -> CleanupRequired -> Reaped/Failed), stacked on #3184.

• Non-throwing kill-and-reap guard, armed immediately after launch and PID capture, holding its own owning reference to the sandbox handle so cleanup is order-independent during unwinding.
• Four injectable seams (pidfd acquisition, registry allocation, monitor-thread launch, sandbox completion) for deterministic fault injection.
• Explicit pidfd outcome classification: a kernel lacking pidfd support (ENOSYS) is the only case that falls back to signalling the sandboxee through its owned monitor handle (SIGKILL, identity-safe, no numeric-PID lookup); every other pidfd error is treated as a resource/identity failure and fails registration outright. Numeric kill(pid, ...) does not appear anywhere in this file.
• A CAS-controlled one-shot latch replacing two-boolean coordination for the timeout-vs-completion race.
• CSandboxedProcessSpawnerLifecycleTest_Linux.cc: fault-injection coverage for every pidfd class, allocation/resource failures, stale-generation protection, PID-reuse identity binding, the CAS race, descriptor-baseline cleanup, and destructor-latency.

Notes

• Not yet compiled or run on Linux/Sandbox2 in this session at the time of opening; being verified against a real Linux devbox in parallel.
• E_Launched/E_CleanupRequired lifecycle states are declared but intentionally left unassigned (no natural single point without broader restructuring) — not silently dropped.
• The SIGKILL-only assumption for the owned-monitor termination path (no graceful-SIGTERM variant is buildable against the pinned Sandbox2 dependency version) was cross-checked against the vendored monitor source during review.

[valeriy42]

Devbox verification (Linux x86_64, real Sandbox2 toolchain): `ml_test_sandbox` filtered to `CSandboxedProcessSpawnerLifecycleTest_Linux` — 13/13 test cases passed, 372/372 assertions, exit code 0.

This surfaced and fixed two real defects that macOS-only syntax checks couldn't catch:

• Two BOOST_TEST_REQUIRE call sites compared non-streamable types (std::future_status, a std::map iterator), which is a hard compile error for that macro (it tries to print both operands on failure). Switched to plain BOOST_REQUIRE.
• The forkserver warm-up used to stabilize the descriptor-count baseline was wired as a BOOST_GLOBAL_FIXTURE, whose constructor runs before Boost.Test finishes its own framework setup. Forking a real process that early corrupted the framework's internal state (every test case genuinely passed, but the run still reported a spurious "Incorrect setup: no test case executed" with a non-zero exit code). Moved the warm-up to a std::call_once-guarded call from inside the normal per-case fixture instead.

Also ran clang-format via the CI's own check image and fixed several workspace-planning-doc citations that had leaked into comments/commit messages (not resolvable outside this internal effort's own tracking) — both now clean.

Buildkite (macOS/Windows legs, full cross-platform CI) still pending.

[elasticsearchmachine]

Pinging @elastic/ml-core (Team:ML)