[BUG][OPT-17] 验证并隔离 streamResult 每次订阅的末态聚合状态 #208

总览：#180

代码依据

问题、范围与验收

finalizeStream 在返回 Publisher 前创建 AtomicReference，返回的流闭包捕获同一引用。对同一个结果流重复或并发订阅时，可能复用或覆盖末态响应；一次成功后另一次无末态时尤其需要验证。此项来自静态闭包分析，尚未运行复现，不能宣称已有跨会话泄露事故。

验收

• 先用可控冷输出源复现同一结果流的顺序重复订阅和并发订阅，分别产生不同末态。
• 覆盖首次成功后第二次中断/无末态、一个订阅取消另一个继续，以及不同 provisional chunks 的场景。
• 若确认共享问题，将末态及其他可变聚合状态放入每订阅 defer 等边界；若 API 确实仅支持单订阅，必须显式声明并可靠拒绝，比较对已有使用方影响。
• 每个订阅最多输出自己的一个最终交付结果；不借用前次 RESPONSE，不互相覆盖 usage/message。
• 现有流式修复、工具调用和取消测试通过；检查冷执行重订阅的副作用语义并记录契约，不用无条件 cache/share 掩盖问题。

不要求未经论证允许同一持久化 Run 重复执行；测试优先在结果转换层隔离验证。

验证与变更约束

代码基线 Core f45b2cf。本单来自静态审查，尚未运行针对性复现或实现。先补行为验证，复用已有能力；破坏性调整逐项说明收益、兼容替代、消费者影响、迁移成本和版本。局部修复不等待 Agent/Workflow/Loop 全局重构，新增通用契约不反向依赖 Loop。