[BUG] Nested background subagent never re-woken by its own children — completion notifications route to the top-level session (2.1.224)

Description

A background subagent (a /code-review skill running as a forked background agent) spawned its own background children (8 "finder" agents plus run_in_background Bash commands). When those children finished, their completion notifications were delivered to the top-level session instead of re-waking the parent subagent that spawned them. The parent also was not re-woken when its own background Bash command (sleep 120 used as a wait timer) completed. Result: the parent stalls indefinitely mid-orchestration ("Waiting for the last three finder agents") until the top-level session manually resumes it via SendMessage. After resuming, it stalls again the same way on the next wait, so a multi-stage orchestration needs a manual nudge per stage.

Possibly the same root cause as #68065 (parent-child association / notification routing for nested background agents), but the symptom differs: here the children's notifications carry their own correct task IDs — they are just delivered one level too high (to the main session), while the level that is blocked on them (the parent subagent) never gets woken.

Environment

• Claude Code 2.1.224 (current stable at time of filing), CLI entrypoint
• Linux WSL2 (6.6.87.2-microsoft-standard-WSL2), bash
• Model: claude-fable-5 (main session and subagents)

Sequence observed (from session transcripts, single occurrence, timestamps local)

1. Main session invokes the code-review skill → runs as forked background subagent (task a9961e3668c6acc7e).
2. Reviewer spawns ~8 background finder subagents; five finish by ~19:39.
3. 19:42:28 — reviewer launches Bash {command: "sleep 120", run_in_background: true} to wait for the last three finders, then stops with text "Waiting for the last three finder agents."
4. The reviewer's stop fires a <task-notification> with status: completed to the main session — even though it is logically mid-task with pending children.
5. The last finders finish by 19:41–19:44 (transcripts complete). No notification re-wakes the reviewer. The sleep 120 completion (~19:44:29) also does not re-wake it.
6. The finders' completion notifications arrive at the main session (correct task IDs, wrong recipient level — the main session did not spawn them).
7. Main session sends the reviewer a SendMessage → reviewer resumes, re-resumes finders/verifiers, and stalls again the same way ("I'll consolidate once their notifications arrive"), with the next round of child notifications again delivered to the main session.
8. Main session ultimately collected the children's results from their transcript files and finished consolidation itself.

Expected

A background subagent that spawns background children (agents or Bash commands) should be re-invoked when those children complete, the way the main session is. Its "completed" notification to its own parent should not fire while it is deliberately waiting on tracked background children.

Impact

Any skill or subagent that orchestrates its own background fan-out stalls at every join point unless a human (or the top-level session) notices and manually resumes it. Silent — the top-level session just sees a premature "completed" notification with an in-progress-sounding result text.

Notes

• The task-notification's own note text says "A task-notification fires each time this agent stops with no live background children of its own" — but the reviewer stopped while it did have a live background child (the sleep), and the children finishing later never woke it, so the documented model doesn't match observed behavior at nesting depth ≥ 2.
• Happy to provide redacted transcript excerpts if useful.