Buffered thread/started notifications can drop subagent names and log raw thread IDs

Bug

When a task spawns a subagent early enough, the job log can lose the subagent name and fall back to raw thread IDs like thr_2.

Reproduction

1. Run a task that quickly spawns a subagent / collaboration tool turn
2. Inspect the resulting job log
3. Observe entries like:
   • Starting subagent thr_2 via collaboration tool: wait.
   • Subagent thr_2 reasoning: ...

Instead of the expected nickname / label (for example design-challenger).

Root Cause

captureTurn() buffers notifications that arrive before the main turn ID is known. During replay, buffered notifications are filtered through belongsToTurn(...).

That works for turn-scoped items, but it is too strict for thread lifecycle notifications like:

• thread/started
• thread/name/updated

If one of those arrives early for a subagent thread, it can be dropped before label registration happens. Later log rendering then has no thread label and falls back to the raw thread ID.

Impact

• Logs and progress output become harder to understand.
• Subagent labeling is unstable and depends on event timing.
• Any future behavior that depends on stored thread labels can inherit the same race.

Suggested Fix

Replay buffered thread lifecycle notifications unconditionally before applying turn-scoped filtering to the remaining buffered messages.

Start by tracing captureTurn() and belongsToTurn(...), then inspect how buffered thread/started and thread/name/updated notifications are replayed. Reproduce the early-subagent case and verify that lifecycle notifications register the nickname before job-log rendering, without changing turn-scoped filtering for other messages.