[Deep Research] Fatal worker errors do not stop sibling capability executions

[Guo-Yixin]

Problem

ResearchRunner executes capability fetches with four concurrent workers. When a worker encounters a fatal error outside the normal capability outcome path, the runner records workerError and stops scheduling new work, but already-running sibling workers continue executing because they only receive the caller's external signal.

This can leave provider calls running after the research run has already failed. Concurrent completion order can also make checkpoint outcomes depend on timing rather than the declared research plan.

Expected behavior

• A fatal worker error should abort in-flight sibling capability executions.
• The first fatal error should remain the root error.
• Persisted capability outcomes should follow the planned capability order.

Proposed scope

• Add an internal fail-stop AbortController combined with the external signal.
• Abort sibling workers when the first fatal worker error occurs.
• Keep checkpoint and outcome ordering deterministic.
• Add a regression test with one fatal worker and one hanging sibling.

[Guo-Yixin]

/claim

我想处理 Deep Research runner 的并发 fail-fast 问题：当一个 worker 发生 fatal error 时，当前已运行的 sibling capability 仍可能继续执行，且 checkpoint outcomes 可能受完成时序影响。我会增加内部 AbortController、稳定 outcome 顺序，并补充 fatal worker + hanging sibling 的回归测试。

[github-actions]

@Guo-Yixin 已认领该 Issue，并已自动设为 Assignee。提交 PR 时请在描述中写 Closes #205。