agent_send reply mishandles parallel and chain background lanes

[quifox]

What happened?

agent_send replies do not behave correctly for multi-task background lanes.

For a completed parallel or chain lane, reply restarts the lane with the original tasks/chain still present, so the new reply prompt is ignored by mode selection and the original work runs again. For a running parallel lane, reply only targets the base sessionId, so sibling child sessions such as sessionId-1 do not receive it.

This conflicts with the documented agent_send behavior that replies continue the lane's existing transcript. I reproduced both cases on clean main @ adcf37b in core subagent tests, without external extensions. I have a local fix and regression tests ready and would like to submit a PR.

Steps to reproduce

1. Start a background parallel lane:

   {
     "tasks": [
       { "agent": "general", "task": "A" },
       { "agent": "general", "task": "B" }
     ],
     "run_in_background": true,
     "alias": "lane"
   }

2. Wait for it to complete.
3. Send agent_send with action: "reply" and prompt C.
4. The original A/B tasks run again; C is not delivered as the new turn.
5. The same completed-lane behavior reproduces with chain.
6. While a parallel lane is still running, a reply reaches the base child but not sibling sessionId-N children.

Expected behavior

A reply should continue the existing lane transcript with the new prompt, preserve the lane topology, and not silently rerun the original prompt. Running parallel replies should not be delivered to only part of the lane.

Version

main @ adcf37b / @step-harness/coding-agent 0.84.4

[xuxujo97-coder]

This comment was generated by AI during triage.

Verification (against current main)

• The reply verb lives in packages/coding-agent/src/features/subagent/lane-lifecycle.ts:289-290 (replyToLane), with live lanes keyed in the same registry — both symptoms (completed parallel/chain lanes restarting with the original tasks/chain so the reply prompt is ignored; running-lane replies hitting only the base sessionId instead of sibling sessionId-1) sit exactly in that routing.

Please open the PR with the regression tests — this is a correctness fix for documented behavior.

[quifox]

@IRemover I have the fix and regression tests ready, but PR creation is currently restricted. Could you add me to the external contributor whitelist when it opens? I can submit it once access is available.