Monitor task list — stale entries persist across app restart + UI/CLI count divergence

Summary

Background-task Monitor entries persist as "Running" in the UI even after being stopped, and the UI count diverges from the CLI count for the same session.

Repro

1. Start an interactive Claude Code session.
2. Arm several Monitor tasks via the Monitor tool, with persistent: true.
3. In the UI, click "Stop" on one or more Monitor entries.
4. Close the Claude Code app entirely.
5. Reopen the app and reattach to the same session.
6. Observe: the stopped Monitor(s) reappear in the UI list as "Running".

Expected

• A monitor stopped via the UI stays stopped across app restart.
• The UI list of running monitors matches the CLI's count for the same session.

Actual

• Stopped monitors return as "Running" after restart.
• UI shows 17 monitors, CLI shows 14 for the same session (3-entry divergence).
• TaskStop from a different originating session silently fails: returns "No task found with ID: …" but the entry remains in the UI.

Environment

• Long-running interactive session (~13 days continuous).
• 14-17 persistent Monitor tasks armed across the session lifetime.
• Linux 6.8.0-111-generic; Claude Code CLI v2.1.150.

Diagnostic notes

• Only one of the monitor tasks (a while true loop) is visible in ps -ef. The others are managed at the app layer and not visible as OS processes.
• No registry file visible under ~/.claude/tasks/<session-id>/ (directory exists but is empty).
• The task output .output files under /tmp/claude-1002/-home-meridian/<session-id>/tasks/ persist even for stopped monitors.

Impact

• UI list becomes cluttered with stale entries that can't be reliably cleaned up.
• Operator can't trust the displayed running-monitor count.
• Some stale monitors with outdated wording (e.g., "First whale-guard fire at \$1000 threshold" — threshold was lowered to \$500 days ago) remain visible and could mislead diagnostics.