Make real-client lifecycle teardown verify the entire tracked process tree #268

Problem

The Windows real-client lifecycle harness can report a deterministic red result even after its fallback cleanup successfully terminates the tracked child process.

Stop-TrackedProcess currently calls .Kill(true) for the root process and waits only on the root handle. It then reopens the child by PID and observes it for only 250 ms. If the child is still alive at that instant, the harness permanently records lifecycle_tracked_child_remained, performs a direct child fallback kill, and can finish with contradictory evidence such as:

• passed = false
• child_exited = true
• exit_before_natural_timeout = false
• cleanup_within_budget = true

On the current Windows host, an exact focused replay failed 5/5 while total cleanup still completed in roughly 443–616 ms. This is a test-infrastructure lifecycle race, not evidence that the shipped Gateway failed to stop.

Related: #108 established the lifecycle contract; #263 covers a different Rust helper/cache cleanup problem.

Required behavior

1. Stop the verified Windows process tree as the primary operation (Invoke-TrackedTreeKill /T /F or an equivalent verified tree-stop primitive).
2. Retain and verify the exact child identity captured before shutdown; do not treat PID reuse as proof about the original child.
3. Verify both root and child termination inside one explicit teardown deadline.
4. A direct-child fallback must be represented as typed degraded cleanup evidence; it must not silently convert an unverified primary tree stop into green evidence.
5. Preserve a deterministic negative control that remains red when the tracked child genuinely survives.
6. Do not fix this by merely increasing the 250 ms observation window or clearing the failure after fallback.

Acceptance

• LifecycleReplay: 30/30 consecutive passes.
• EnvironmentIsolation: 30/30 consecutive passes.
• Loaded/concurrent rounds remain green.
• For the positive path, root and verified child both exit before their natural timeout and within the existing 6000 ms cleanup budget; no lifecycle failure is recorded and both PIDs are gone.
• The negative control remains red and explains which verified process survived.
• Result fields cannot contradict one another: any fallback/degraded path is explicitly typed and summarized consistently.

Verification

Verification class: strict (process lifecycle, concurrency, and nondeterministic runtime evidence).

Run the focused lifecycle harness repetitions above, then the complete Python core suite at the exact candidate SHA. CI must pass on the repository Windows runner.