/clear orphans background tasks by modifying session state in place

/clear modifies the harness's session state in place rather than starting a fresh session. Background tasks the previous conversation started are left orphaned: they keep running, their completion notifications keep arriving in the new conversation, but the new conversation has no way to enumerate them — so their task_ids are unknown and TaskStop can't be used.

Repro

1. Start a long-running background bash task (e.g. sleep 600 via Bash with run_in_background: true).
2. Run /clear.
3. Ask the model to list or stop background tasks.

Observed

• Tasks continue running.
• <task-notification> events for them arrive in the new conversation, referencing the pre-clear session-id.
• There is no <background-tasks> system reminder and no list tool, so the model cannot discover the task_ids. The only way to learn one is to wait for the task to terminate and read it off the completion notification.
• Falling back to OS-level ps/kill by PID works, but requires the user to know which PIDs.

Suggested fix

Either adopt the framing implied by /clear and tear down orphaned tasks with the conversation, or surface them to the new conversation (e.g. a <background-tasks> system reminder listing inherited task_ids and descriptions) so the notification stream matches the model's visibility.

Environment

Claude Code CLI.