[Feature]: 支持流式输出中的过程文本与最终答案分流

背景
在多轮 ReAct 或工具调用场景中，模型通常会先输出一段规划、分析或决策文本，然后调用工具，最后再生成面向用户的最终答案。
目前流式事件中的文本增量缺少明确的语义区分。调用方只能看到连续的文本事件，无法可靠判断某段文本属于：
- 面向用户的最终答案；
- 工具调用前的中间过程；
- 工具调用后的补充说明；
- 尚未确定是否为最终答案的临时内容。
当前问题
1. 中间文本可能被误展示给最终用户
模型在调用工具前输出的规划内容，可能会被前端或上层应用直接展示。
这会导致：
- 内部决策过程暴露给用户；
- 中间结论与最终结论混杂；
- 不同模型的输出风格导致展示效果不一致；
- 应用方需要自行编写复杂的过滤逻辑。
2. 直接等待最终结果会损失流式体验
一种简单处理方式是等待 AgentResultEvent，确认本轮没有工具调用后，再一次性输出文本。
但这种方式会：
- 增加用户等待时间；
- 失去文本逐步到达的体验；
- 使长文本响应无法及时显示；
- 降低 AG-UI、WebUI 等交互界面的实时性。
3. 文本是否为最终答案，需要在轮次结束后才能确认 PR #2926
在模型文本刚开始流出时，调用方通常无法立即判断它是否会紧接着触发工具调用。
只有当本轮模型输出结束后，才能确认：
- 本轮是否产生工具调用；
- 本轮文本应被视为中间过程还是最终答案；
- 是否需要向最终用户展示这段文本。
因此，该问题不适合完全由前端或业务层单独解决，需要框架提供统一的语义表达。
4. 各适配层的行为可能不一致
目前不同输出通道对中间文本和最终文本的处理方式可能存在差异，例如：
- Agent 原生事件流；
- Agent Protocol；
- AG-UI；
- Web/DataPlane；
- 前端状态管理。
这会导致相同一次 Agent 执行，在不同客户端中出现不同的展示结果。
改进建议
建议在框架层明确表达流式文本的输出语义，使调用方能够根据使用场景选择不同的展示策略。
1. 提供文本语义分类
流式文本至少应能区分：
- 中间过程文本；
- 最终答案文本；
- 尚未确定归属的文本。
分类结果应随事件流传递，并保持跨适配层的一致性。
2. 同时支持两种消费模式
框架应支持以下两类使用方式：
完整流模式
调用方可以获取全部文本，包括：
- 中间过程；
- 工具相关过程；
- 最终答案。
适用于调试界面、内部观测、Agent 可视化和过程追踪。
最终答案模式
调用方只接收确认属于最终答案的文本，不需要自行处理工具调用和中间过程。
适用于：
- 面向最终用户的聊天界面；
- 对外 API；
- 需要隐藏内部过程的产品场景。
3. 保持流式体验
在能够确认文本语义后，应尽可能继续以增量方式输出最终答案，而不是强制等待整个 Agent 执行结束后再一次性返回。