fix(deepresearch): fix ResearchTeamNode error and missing edge from research_team to planner, preventing possible infinite loop

[ichaobuster]

本PR修复以下问题：

• ResearchTeamNode 目前的逻辑会造成进入parallel_executor后可能出现curPlan为null的现象，且可能因此造成research_team_next_node一直为parallel_executor而造成流程进入research_team后死循环。
• 根据 ResearchTeamDispatcher ，默认的情况下路径会进到planner，而 DeepResearchConfiguration 中从research_team出发的conditionalEdge缺少planner的mapping，因此也会造成流程无法运行到END。

---

This PR addresses and fixes the following issues:

• ResearchTeamNode's current logic can lead to a scenario where curPlan becomes null after entering the parallel_executor. This can subsequently cause the research_team_next_node to perpetually remain the parallel_executor, resulting in a deadlock once the flow enters the research_team.
• According to the ResearchTeamDispatcher, the default path leads to the planner. However, the DeepResearchConfiguration is missing the planner mapping in the conditional edge starting from the research_team, which also prevents the flow from reaching END.

[ichaobuster]

PTAL, thank you! @yuluo-yx @VLSMB @GTyingzi @benym

[benym]

I have some questions about when curPlan becomes empty.
The InformationNode code should generate a Plan, and if the Plan serialization is empty, it should retry generating it, and then stop after reaching the specified number of attempts.
At this point, it's not yet time to reach the ResearchTeamNode.

[ichaobuster]

I have some questions about when curPlan becomes empty. The InformationNode code should generate a Plan, and if the Plan serialization is empty, it should retry generating it, and then stop after reaching the specified number of attempts. At this point, it's not yet time to reach the ResearchTeamNode.

@benym When I config to use other LLMs, I may encounter situations where curPlan is null or empty list, and this phenomenon does not occur consistently.

[benym]

From the call path perspective, even if the output during Plan deserialization is indeed null, when it reaches ResearchTeamNode, Plan curPlan = StateUtil.getPlan(state) will throw an NPE because current_plan is null, instead of continuing to subsequent nodes. Therefore, I don't think the problem you mentioned exists.
Instead, the deserialized result should be checked in com.alibaba.cloud.ai.example.deepresearch.node.InformationNode#apply.
If Plan is indeed null, an exception should be manually thrown to retry the process.