长任务对话后页面卡死无法动弹

[littersnaker]

因为卡死了，我没法看到是否用了虚拟滚动，可以考虑一下做一下滚动类型的优化，其实速度我觉得是可以的，而且质量也行，可能是我任务比较简单，但是前端部分很多优化是没做到的

[HualuozhE]

同样遇到"长任务后页面卡死"，补充本次实测的规模数据，供虚拟滚动/渲染优化参考：

• 单轮 turn 产生 109,430 个事件序号；其中 3,242 条 reasoning-chunks（合计 116.8 万字符）在约 15 分钟内实时累积渲染；
• 一条 assistant/message 单行 JSON 866,523 字符：正文约 29 万字符、42 个代码块，sourceEventSeqs 聚合 9.7 万个流式 chunk；
• 最后 3 秒内 1.35 MB 的 chunk 突发（约 460 KB/秒）；
• 页面冻结后到达的 approval/asked（沙盒权限提升）无法点击，turn 永久悬挂，只能归档会话。

支持"虚拟滚动 + 超大文本截断 + 高亮移出主线程"的优化方向；另见 #2119（history 分页负载）与 #511（卡死后的运行状态）的机制讨论。

[V1sMu21]

顺着「卡死」这条线排查后定位到渲染路径，方案已实现并测试通过，完整说明放在 #7579：

• packages/client/ui-chat/README.md 原文："Stable Chat Node Seats keep every renderer mounted"
• Chat 对整个已加载窗口逐个渲染 ChatNodeSeat，而 Turn 过程折叠只做 hidden="until-found"（searchable-hidden.ts）——子树不卸载
• 于是「折叠已完成轮次」只是绘制层隐藏：每次 commit 的协调成本、保留的 element tree 与 DOM 都仍是 O(已加载节点数)，随会话时长单调增长

ui-trajectory 早就为同样原因虚拟化了（e2e 断言 MAX_MOUNTED_ROWS = 160），Chat 缺对等机制。

改动方向：render 期把已加载 order 投影到固定轮次预算（默认最新 5 轮），更早轮次收敛成 1 个折叠行，挂载行数与会话长度解耦；折叠行按页上抬，上限 8 页后由「加载更早」接管。

在 12 轮×6 行 与 40 轮×2 行两种会话上，挂载行数实测相同。单测 31 files / 369 tests 全通过。

（本仓库 Issues 与 PR 入口均未开放，因此按 Discussion 提交。）