Flaky: pty::sessions process-teardown tests fail intermittently in CI

[ElbertePlinio]

Two different tests in crates/pickforge-core/src/pty/sessions.rs have each failed once in CI within the last hour, on unrelated changes. Both are Linux-gated, so they cannot be reproduced on a macOS dev machine.

Run	Branch	Test
30182950477	main	terminate_owned_process_trees_kills_child_and_grandchild_by_exact_identity
30184151371	feat-parser-tool-detail (#387)	dtach_cleanup_kills_a_resistant_child_forked_from_a_term_handler

Both were 755–768 passed; 1 failed, in the rust coverage step. The #387 failure is provably unrelated to that PR — it changes claude_stream.rs and frontend stores, nothing under pty/. The main failure is on a commit that also touches neither.

Why this matters more than a normal flake

• It is Linux-only (#[cfg(target_os = "linux")]), so nobody on macOS can reproduce or bisect it locally. The repo's own AGENTS.md already warns that Linux-gated code must be validated on real Linux.
• It surfaces in the rust coverage step under cargo llvm-cov, which changes process timing — worth checking whether it is reproducible under plain cargo test at all, or only under instrumentation.
• Both tests assert on process teardown by exact identity — killing a child that resists SIGTERM, and killing a grandchild. That class is inherently timing-sensitive: a fork racing a signal, a pid reused, a waitpid landing a scheduler slice late.
• It costs a full CI cycle each time and, worse, invites the wrong conclusion — the first instinct on a red build is to suspect the diff.

Suggested investigation

1. Run both tests in a loop (say 200 iterations) on a Linux container, under cargo test and under cargo llvm-cov, to establish the rate and whether coverage instrumentation is implicated.
2. Look for an unbounded wait or a fixed sleep in the teardown assertion; the existing PICKFORGE_HOME_ENV_LOCK convention suggests this module already has known cross-test interference.
3. If it is a genuine race in the test rather than the code, make the wait condition-based. If it is a race in the teardown code, that is a real bug in process cleanup and matters well beyond CI — Guarantee process-tree teardown on PickForge exit or crash #208 is about guaranteeing process-tree teardown.

Not blocking anything today; re-running cleared #387. Filed so the next red build on an unrelated PR is diagnosed in a minute instead of half an hour.

Refs #208