[BUG] Windows terminal CLI: idle session intermittently kills long-running background Bash tasks with nested claude -p children (status=killed, "was stopped")

Environment: Claude Code 2.1.216, Windows 11, plain terminal CLI (parent=powershell.exe; NOT Desktop-embedded), bypassPermissions, long-lived interactive session (~3 days, heavy use).

Summary: Background Bash tasks (`run_in_background`) whose process tree contains a nested headless CLI (`bash → python → claude -p` worker, or `codex exec`) are intermittently stopped by the harness while the session is completely idle. The transcript records a `queue-operation` task-notification with `killed` / summary `Background command "…" was stopped`. No TaskStop tool call, no user interrupt, no UI action.

Evidence (from the session transcript + OS logs):
- 9 kills over 3 days in one session; lifetimes 42s, 114s, 202s, 345s, 1093s, 1187s, 1344s, 1966s, 2049s — no consistent timeout.
- ~57 same-shaped background dispatches in the same session completed fine (longest 2h06m); shallow background tasks (pollers/watchers) were never killed.
- Both recent kills landed while the session was idle (108s and 37s after the turn ended; stop hooks had completed within ~6s of turn end).
- Worker processes were alive and writing logs until the exact kill moment (196KB in 2 min), then cut with no error.
- Windows Event Logs (System incl. Resource-Exhaustion, Application 1000/1001/1002, Defender) are empty in the window; 21/64GB RAM free.
- Zero `[Request interrupted]` records in the entire 27.7MB transcript.
- Project hooks audited: no taskkill/Stop-Process/pkill logic that could reach these PIDs.

Expected: a background task keeps running across turns until it exits or is explicitly stopped (TaskStop / user).
Actual: harness intermittently stops it (status=killed) with no actor identifiable from the transcript.

Workaround verified: detaching the worker from the session (PowerShell `Start-Process`, i.e., outside the session's process scope) + polling a status file from the session — 4/4 subsequent workers completed on the same machine/workload.

Possibly related: #25188, #8865, #68625 (Desktop WarmLifecycle — different entry point but same taskkill-tree substrate), #72851.

Ask: what harness-side reaper/lifecycle can stop a background task on Windows while the session is idle, and can it exempt (or at least log a reason for) tasks with live child trees? Happy to provide the full evidence bundle (delta table, transcript excerpts).

Start at the plain terminal CLI entry point and the run_in_background process-lifecycle path, comparing behavior with the documented TaskStop path. Reproduce the Windows idle-session case using the nested bash → python → claude -p or codex exec tree, then identify the harness actor and make completion or explicit stopping distinguishable from unexplained kills.

Written by the indexing model from the issue text.