Monitor: log-follow watch gives no signal when the log's writer dies; request a liveness/exit event

Context

The background-task kill bug (#84625, #88071 family) pushes long-running work to nohup/setsid detachment, which forfeits the harness's own completion notification for run_in_background tasks. The documented fallback for tracking detached work is a Monitor tailing the task's log file.

Problem

A tail -f log | grep --line-buffered PATTERN monitor is only as good as its filter. If the detached process fails fast with a message matching no pattern, tail keeps the pipeline alive forever on the now-silent file: no event fires, and there is nothing distinguishing "still running" from "died in the first minute."

Real cost observed: a multi-stage validation chain exited within ~1 minute of launch on a precondition refusal whose wording matched none of the filter's alternations. The session believed it was running for ~6.5 hours until the human asked "is this hanging?".

The model can mitigate by convention (wrapper scripts that always echo exit=$?, filters that match every terminal state), but it is a recurring footgun under exactly the conditions the kill bug creates.

Request

Any of these would close the gap:

1. An optional watch_pid input on Monitor: emit one final event when that pid exits, regardless of the filter.
2. A built-in advisory event when the followed file has been quiescent for N seconds.
3. Fixing the underlying kill bug so detachment is unnecessary and run_in_background's native completion notification suffices.

Environment

Claude Code 2.1.258, macOS (darwin 25.6), zsh.