bug: /fork context contaminates main session on switch-back

Summary

Switching back to the main session after a /fork causes the main session to receive and respond to the fork's topic, interrupting whatever the main session was doing.

Steps to reproduce

1. Start a main session actively working on Task A
2. Run /fork <different topic> — fork does substantive work on Topic B
3. Fork completes or is left mid-work
4. Switch back to the main session
5. Main session responds to Topic B instead of continuing Task A

Actual behavior

On switch-back, the main session's context was contaminated with the fork's conversation. The model began producing output on the fork's topic, then self-corrected mid-sentence:

You're right — I derailed onto the fork's topic. The fork exists precisely so the main thread stays on the loader. Resuming the seeding skill now. I have everything I need (encryption scheme, record layout, proto shape, serveability fields, tweetnacl location). Building it.

  Ran 1 shell command

● Agent "confirm our indexing strategy on the persons sear…" came to rest · 5m 58s

Fork notifications are background — ignoring them, staying on the loader. nacl copied. Now the seeding script (clone-decrypt-mutate-reencrypt, raw IDB write, integrity self-test, reset):

The self-correction ("You're right — I derailed") confirms the model itself detected the context mismatch, but the contamination had already produced visible output in the main thread.

Expected behavior

Switching back to main resumes the main session exactly where it left off, with no awareness of the fork's content.

Impact

The fork's purpose is to explore a side topic without disturbing the main session. Context bleed on switch-back defeats this entirely — the main session is interrupted and the user's in-progress work is derailed.

Environment

• Claude Code (CLI)
• Platform: Windows 11 (win32)