`send_and_wait` resolves on a sub-agent's `session.idle` / `session.error`

[Lukaze]

Repo/version: github/copilot-sdk, tag rust/v1.0.14 (e60d903); CLI runtime 1.0.84-5.

Behaviour: A parent turn's send_and_wait returns early, with the wrong result, when a spawned sub-agent fails or goes idle.

Cause: handle_notification (rust/src/session.rs:2256; the waiter arm :2282-2304) takes the send_and_wait waiter on every session.idle / session.error and records every assistant.message as the wait's last message, with no agent_id check. The CLI's subagent bridge re-emits child events on the parent stream carrying the child's agent_id (the CLI runtime re-emits sub-agent events on the parent stream tagged with the child agent_id; session.error is among the re-emitted types), so a child's model-call failure resolves the parent's wait.

Fix shape: Only events with no agent_id (or equal to the root session's) may resolve the waiter or set its last message. Child-tagged idle/error/message events are ignored by the waiter (they still reach on_event).

Regression test: parent wait in flight; inject session.error with a child agent_id → wait NOT resolved; inject root session.idle → resolved.

Downstream: a consumer of this crate carries a local patch for this and cannot drop it until it is fixed upstream.

[Lukaze]

Suggested fix shape, to avoid trading one hazard for another: signal the waiter only when the event's agent_id is absent, empty, or equal to the session's own root agent id. An absent-or-empty-only gate breaks the day the CLI starts stamping the root id on root events — the waiter would then never resolve and a fast failure becomes a silent timeout. The equality arm keeps the fix correct under both CLI behaviours.

Verification trap for anyone re-checking on 1.0.15-preview.0: the agent_id gate at rust/src/session.rs in StructuredOutputState::observe is a different code path, not the send_and_wait waiter; a naive grep reads it as already fixed.

[Lukaze]

Refinement to the fix shape above: the protocol exposes no root agent id today (root events omit agentId; create/resume results carry none), so an "== root id" arm has nothing to compare against. The derivable form: resolve the waiter when agent_id is absent/empty or not among the child agent ids the session has observed from subagent lifecycle events. That is correct under the current CLI, stays correct if a future CLI stamps the root with any id, and its only failure mode (a child whose start event was never seen) is the existing behaviour — never worse.