[BUG] Session lock alone (no sleep, no quit) kills long-running background tasks in Claude Desktop

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet in this exact form
• [x] This is a single bug report
• [x] I am using the latest version of Claude Code

What's Wrong?

Background tasks started with run_in_background: true (e.g. a long-lived gh run watch polling a CI run, or a background subagent) get silently killed while the user is away from the machine — even when:

• the laptop is not put to sleep,
• the laptop is not powered off, and
• the Claude Desktop app is not manually quit.

The only thing that happens is the user locks their session (or simply stops interacting) for roughly 5-30 minutes and then returns and unlocks. On return, the background task is gone/dead with no error surfaced, and any watcher relying on it (e.g. one asked to "watch this run and keep me informed") has silently stopped making progress.

This matches the mechanism already traced in #68625 (Desktop's WarmLifecycle idle-session manager tearing down the embedded CLI's process tree — idleTimeoutMs: 900000, timeoutOnHidden: true — via taskkill /T /F on Windows or a process-group SIGTERM on macOS) and #23092 (macOS SessionIdleManager with a hardcoded 300s idle-quit). Both were filed for slightly different angles (Windows-traced internals; full-app-quit on macOS) and #23092/#32050 were closed by the stale bot without a fix. This issue is to consolidate: the trigger is lock-screen / inactivity alone, not OS sleep or an explicit quit, and it affects the general "ask Claude to watch/monitor something long-running and walk away" workflow, not just Desktop-specific window-hidden states.

What Should Happen?

Background tasks (and the session they belong to) should survive user inactivity/lock indefinitely, or at minimum the idle-teardown should be configurable/disableable (e.g. a --no-idle-timeout flag or per-session setting), and the background-task UI should reflect the actual killed state instead of continuing to show "running" after teardown.

Related Issues

• #68625 — traces the Desktop WarmLifecycle teardown mechanism (Windows-confirmed, macOS suspected via SIGTERM)
• #23092 — macOS SessionIdleManager 300s hardcoded idle-quit (closed by stale-bot, not fixed)
• #32050 — general report of session idle-disconnect losing long-running background task results (closed "not planned")

Environment

• Platform: macOS (Darwin)
• Trigger: session lock / inactivity only — confirmed no sleep, no app quit