[BUG] Background task handles are instance-scoped but task registry is session-scoped — compaction orphans live processes

Summary

Claude Code creates OS-level process handles that are owned by the instance (the running Claude Code process), but the task registry that maps task IDs to those handles is session-scoped. Context compaction creates a new session without transferring the registry. Result: the OS processes keep running, but TaskOutput and TaskStop can no longer reach them — the handles are live but permanently orphaned.

This is distinct from #22670, which is a notification/counter UI bug (the status bar counter not decrementing after OS task completion). That issue does not involve unreachable live processes.

Root Cause

The mismatch:

| Resource | Scope |
|---|---|
| OS process (bash subprocess, agent subprocess) | Instance — lives until the Claude Code process exits |
| Task registry entry (task ID → process handle) | Session — reset or dropped on compaction |

When auto-compaction fires, the new session starts with an empty task registry. Pre-compaction task IDs are unknown to it. Any TaskOutput/TaskStop call using a pre-compaction ID returns "no such task" immediately, even though ps shows the process still running.

Steps to Reproduce

1. Start one or more background tasks via Bash(run_in_background: true) or Task(run_in_background: true).
2. Continue working until auto-compaction fires.
3. In the new post-compaction session, call TaskOutput with any pre-compaction task ID.
4. Observe: "no such task" — the process is still alive at the OS level but unreachable through the tool.

Expected Behavior

Task handles should be stored at instance scope, not session scope. TaskOutput and TaskStop should look up the process handle from the instance-level registry, making them session-agnostic. Task IDs created before compaction should remain valid and functional in the post-compaction session.

Actual Behavior

After compaction, all pre-compaction background processes are permanently unmanageable:

• TaskOutput returns "no such task"
• TaskStop returns "no such task"
• No way to retrieve output or stop the processes short of killing the Claude Code instance
• Processes run to completion (or run indefinitely) consuming resources silently

Environment

• Claude Code v2.1.59
• Linux
• Observed: 2026-02-26 (US CST)
• Background tasks via Bash(run_in_background: true) and Task(run_in_background: true)

Related Issues

• #22670 — Background task counter not decrementing after completion or compaction (different root cause: notification/UI layer bug, not resource handle ownership)
• #27319 — Stale plans after compaction (adjacent: session state loss, framed as context loss)