Stale monitor timeout notification delivered after the monitor was superseded reads as a current event

Type: bug
Area: Monitor / background-task notifications

Environment: Claude Code CLI, Monitor tool, long session with multiple monitors on the same target over time.

Summary

A Monitor's terminal notification (e.g. a timeout) can arrive after that monitor has been superseded by a newer monitor watching the same target. The notification's summary text reads as a current event, and nothing in it signals that it belongs to a defunct watch. In a session running several concurrent streams, a stale timeout event is indistinguishable from a live one and invites acting on a signal that no longer reflects any running work.

Steps to reproduce

1. Arm a monitor on some target.
2. Supersede it with a second monitor on the same target (the first is now logically stale).
3. Let the first monitor hit its timeout.
4. Observe its timeout notification arrive, phrased like a current event.

Expected

Terminal/timeout notifications from a superseded monitor should be clearly attributable — surface the monitor's own description/target in the event line so a stale one is recognizable at a glance (the task-id is present, but the human-readable summary can still read as current).

Actual

The stale timeout notification reads as a current event; only cross-referencing the task-id against the active monitor reveals it is defunct.

Impact

Confusion in long multi-stream sessions; risk of reacting to a signal from a monitor that is no longer running.

Suggested direction

Include the monitor's description in every event line (not just the task-id), and mark terminal events from monitors that have been superseded.

Filed from real usage; sanitized.