[Bug] TaskNotificationMessage fires while subagent is still running (premature, not cross-turn leak)

**Summary**

When an orchestrator dispatches multiple subagents in parallel via the Task tool, the SDK occasionally delivers a TaskNotificationMessage (as a SystemMessage injected into the
orchestrator's context) while the referenced subagent is still actively executing tool calls. The actual TASK_DONE / ResultMessage arrives minutes later.

This is distinct from #788 (which is about notifications leaking between turns). Here the notification fires within the same turn, but before the subagent has finished — the subagent continues running for 76–850 seconds after the orchestrator receives its "completion" signal.

The bug is non-deterministic: two identical runs with the same code and prompts show different behavior. Run 1 (broken), Run 2 (correct, normal TASK_DONE sequencing).

---
**Environment**

- claude-agent-sdk Python, SDK-native orchestration
- Platform: WSL2 (Linux 5.15.167.4-microsoft-standard-WSL2)
- Lead model: claude-sonnet-4-6, max_turns=15, allowed_tools=["Task"]
- Subagent model: claude-sonnet-4-6 (inherited)
- 5 subagents dispatched in parallel, each running 40–61 tool calls

---
**Reproduction**

1. Orchestrator dispatches 5 long-running subagents in parallel via Task
2. Each subagent runs ~40–60 tool calls (total wall time ~400–800s per subagent)
3. Observe whether for each subagent arrives before or after that subagent's ResultMessage

Reproduction is non-deterministic. In our testing: 1 of 2 identical runs triggered the issue.

---
**Expected Behavior**

TaskNotificationMessage / is delivered to the orchestrator only after the subagent has emitted its final ResultMessage and completed all tool calls.

---
**Actual Behavior**

All 5 subagents received premature injected as SystemMessage into the Lead's context while still mid-execution. The Lead's model included the raw XML in its text output, acted on it as a
completion signal, and immediately dispatched downstream agents against files that hadn't been written yet.

Timeline (Run 1):

Log excerpt showing the XML embedded in Lead's model response text while R2 is still at tool=13 of its eventual 39 total tools:

[16:35:16] [LEAD] [text] R1 completed → Reviewer-1 has immediately dispatched。continuing to wait for remaining researchers.
Task aa3bf63ec4f676663 (R2 subtopic.x) has completed.

[16:35:17] [TASK_PROG] [aa3bf63e] last_tool=WebFetch tools=13 tokens=36,116 elapsed=64.5s
← R2 is still running; Write call occurs at tool=39, 466s later

The remaining 4 researchers' notifications arrived within 60 seconds of each other (16:35:16–16:36:21), all premature, all while the subagents were still running.

---
**Cascade** Impact

The orchestrator prompt uses an event-driven pattern ("subagent-X completes → immediately dispatch reviewer-X"). Premature notifications caused:

1. 5 reviewer subagents dispatched against output files that didn't exist yet
2. Orchestrator re-dispatched all 5 researchers (~8 min wasted)
3. All 5 original researchers' actual TASK_DONE arrived ~17 minutes later, flooding the orchestrator with stale notifications
4. Total run: 32 min / $21.51 (baseline identical run: 51 min / $22.33 — no premature notifications, correct sequencing)

---
**Request**

1. Clarify whether TaskNotificationMessage delivery timing is guaranteed post-completion or best-effort
2. If it should be post-completion: this is a bug in notification delivery — the notification fires before ResultMessage
3. If best-effort by design: please document this limitation and consider providing a reliable completion signal (e.g., a flag on TaskNotificationMessage indicating whether ResultMessage has already been
emitted)