Detect owned target exit while waiting for a managed runtime first frame #709

A contained Gemini bootstrap reached Node, rejected its private-profile validation, and exited before sending its first hello frame. The parent still waited the full 60-second interaction deadline. The retained diagnostic reported hello=false, ready=false, sequence=0, and the bounded static error bootstrap: private_profile; no provider request or authentication was involved.

The shell-intrinsic profile mismatch is being corrected separately. The general parent wait remains: ContainedProcessSession::check_private_channel_live in src/process_runner/part3.rs checks cancellation/deadline and drains output, but does not establish whether its exact owned target already exited. The first-frame accept loop in src/external_agent/gemini_bridge.rs therefore keeps waiting after an early bootstrap failure.

This differs from #697, which covers attachment-stage diagnostics before target release.

Acceptance:

• Detect exit of the exact owned target while waiting for the first managed-runtime frame; retain its launch identity and avoid treating PID reuse or unavailable ownership evidence as a known exit.
• Drain and retain bounded startup diagnostics and the actual terminal/cleanup result before returning failure. Never turn EOF or missing frames into successful protocol completion.
• Keep claims, worktree leases, and process custody until owned-process quiescence is verified; preserve conservative handling of unknown descendants.
• Keep existing startup and total deadlines and all confinement, peer-identity, and protocol validation checks.
• Add a deterministic contained test whose target exits before hello, and a live-but-silent target that still obeys the existing deadline. Cover missing/uncertain exit evidence without exposing environment values, credentials, nonces, or full guardian commands.

The observed installed-bootstrap test is external_agent::gemini_bridge::tests::gemini_bridge_real_installed_bootstrap_retains_quiescent_no_release. Its early-exit failure remains a failure; the diagnostic alone does not qualify a usable Gemini runtime.