Background job writes completion output into the wrong thread — job spawned in Thread A bleeds into Thread B if B is active when the job finishes

Bug Description

A background job spawned from Thread A writes its output into whichever thread is currently foregrounded when it completes — not back into Thread A where it originated. If the user switches to Thread B for unrelated work while the job runs, that job's results land in Thread B instead of Thread A.

Both threads survive intact up to that point, but after the job completes, Thread B contains output that belongs to Thread A, and Thread A has a gap where the results should be.

Reproduction Steps

1. Start Thread A — do some work
2. From Thread A, start a background job (logically part of Thread A's work)
3. Switch to Thread B to do unrelated work while the job runs
4. The background job completes
5. Result: The job's output is written into Thread B's JSONL — not Thread A's

Expected Behavior

A background job should write its results back into the thread where it was spawned, regardless of which thread is active when it finishes.

Actual Behavior

The job's resumeSessionId is resolved at completion time against the currently active session, not the session that spawned the job. Thread A has a gap. Thread B has output that doesn't belong to it.

Impact

• Switching threads while a job runs silently misroutes that job's entire output
• No warning is shown — only discovered after noticing content in the wrong place
• Switching threads during a long-running job (the normal use case for background jobs) reliably triggers this

Environment

• Claude Code: 2.1.195
• OS: Ubuntu Server 24.04
• Terminal: Tabby
• Multiplexer: Zellij
• Note: Tabby + Zellij may be relevant if session/pane focus detection plays a role in which thread is considered "active" at job completion time

Notes

Background jobs are specifically designed for "fire and switch" workflows — the whole point is to start a job and go do something else. The current behavior makes that unsafe: any thread switch while a job runs risks contaminating an unrelated thread.