Resource Monitor: narrow PID-reuse kill-safety edge (unreadable recycled root with readable child)

[mblua]

Follow-up to #516.

Context

#516 added a root-PID-reuse guard in observe_tree/build_observed_tree (src-tauri/src/resource_monitor/windows.rs): when the live process at a group's registered root PID has a creation time that differs from the expected root_identity, the subtree is dropped (so a recycled root PID can't be adopted and later killed). This closed the common readable-foreign-root case.

Remaining narrow edge

If a recycled root PID is occupied by a foreign process whose own identity is UNREADABLE (creation_time == 0 → the new guard is skipped, kill_allowed=false for that node), but that foreign process has a READABLE child, the child is still walked and can get kill_allowed=true. A later kill could then terminate the foreign child.

This was fully open before #516 and is now strictly narrower (the common case is caught). It requires an unlikely combination: same-user PID reuse + unreadable foreign parent + readable foreign child + a kill trigger.

Possible fix direction

Extend the guard so a creation-time-unverifiable root also drops/quarantines its subtree (treat an unreadable root as "do not adopt descendants"), matching the strictness applied to the mismatched-root case.

Severity: LOW, pre-existing, narrow. Identified during #516 adversarial review.

[mblua]

Delivered ✅

Landed via PR #572 (admin-merge), merge commit da929a1, on main. Version 0.9.14 (no bump — normal landing, per policy version advances only at a GitHub Release).

What changed

• Backend only (src-tauri/src/resource_monitor/windows.rs, build_observed_tree): extended Add detachable resource monitor and process guardrails #516's root-PID-reuse guard so a registered root whose live identity is unverifiable (creation_time == 0) also drops its subtree — closing the narrow edge where an unreadable foreign parent (recycled root PID) with a readable child could let that foreign child become kill_allowed = true.
• Chose DROP (mirrors Add detachable resource monitor and process guardrails #516) over a new quarantine abstraction; the drop is re-evaluated every observe cycle, so it behaves as a self-healing soft-quarantine — a legitimately-but-briefly-unreadable own root is never permanently orphaned.
• Reordered so identity resolves before the placeholder push → emits exactly one missing-root error (matches Add detachable resource monitor and process guardrails #516's single-error contract).
• New unit test unreadable_root_drops_subtree_and_protects_readable_child; all four Add detachable resource monitor and process guardrails #516 guard tests stay green.

No own-cleanup regression

kill_group builds targets from the accumulated observed_processes (add-only), and the reap path stays gated by the #559 observe_identity confirm (alive-but-unopenable root → Err → reap aborts; only genuinely-gone or recycled roots are reaped). So our own runaway subtree stays killable even during a transient unreadable window.

Tested

• dev-rust: full suite cargo test --lib --bins --tests → 1347 passed / 0 failed; clippy clean; /code-review (high) → 1 candidate refuted, 0 HIGH.
• grinch (adversarial Step-7): CLEAN — all 5 load-bearing claims verified against the code; 41 resource_monitor tests pass incl. the Resource Monitor: agent groups never evicted — ACTIVE GROUPS pins at max (slot leak) #559 reap gates.
• shipper: built v0.9.14 from the branch, deployed agentscommander_standalone_wg-1.exe to 0_AC.
• user: manually tested the deployed 0_AC exe (normal agent-lifecycle regression check — stop/restart/assign + Resource Monitor cleanup) and approved landing.

CI

PR #572: frontend-regression, rust-regression, test-debt, validate-branch-name, windows-release-cli-smoke — all green.