Background agent notifications route through wrong agent ID when launched sequentially (2.1.172+)

Description

When two independent background agents are launched sequentially (second spawned after first's completion notification), the second agent's completion notification arrives on the first agent's task ID. The second agent never sends its own notification. In the execution tree, the second agent appears as a subprocess/child of the first, despite being an independent Agent() call.

Repro

1. Launch Agent A with run_in_background: true
2. Wait for Agent A's completion notification
3. In the same turn, launch Agent B with run_in_background: true
4. Observe: Agent B's completion notification arrives on Agent A's task ID. Agent B's own task ID never fires.

Agent types don't matter (reproduced with generator and reviewer subagent types). The key factor is sequential launch where Agent B is spawned in the callback context of Agent A's completion.

Affected versions

• Reproduces on: 2.1.172 through 2.1.176
• Clean on: 2.1.169

Suspected cause

The sub-agent nesting feature introduced in 2.1.172 ("Sub-agents can now spawn their own sub-agents") uses implicit parent-child association based on execution context. When Agent B is spawned while the orchestrator is processing Agent A's notification, the nesting logic incorrectly parents Agent B to Agent A instead of to the orchestrator.

Possibly related to the worker reuse fix in the same release ("Fixed background agents potentially reading another directory's project settings when dispatched onto a pre-warmed worker") — agent identity/parentage may leak through the same worker reuse path that project settings did.

Impact

Orchestrators that track agent completion by task ID miss the second agent's completion entirely, since it never fires on its own ID.