[buxuku]

批量处理约 150–200 个文件时，读取/哈希进度会频繁触发整批数据克隆、投影和广播，任务列表和实时日志进一步放大界面负载。本次降低这条链路的开销，并在界面进程意外退出后提供恢复当前项目的入口。

修改

• 在整批克隆和投影之前合并进度与活动更新，每 200ms 至多发布一次，保留对外快照隔离。
• 纯进度检查点从 500ms 调整为 2s；关键状态立即保存，正常退出补存进度，阶段提交撤销过期的通知。
• 50 个文件以上的列表采用动态行高虚拟化；任务日志面板仅保留最近 200 条。
• 界面进程意外退出后提供原生恢复提示，重载当前项目并读取后台状态，后台任务继续执行。
• 补充回归测试及 docs/issue-574-performance.md 中的证据、修复说明和范围。

验证

• 已同步当前 main，类型检查及生产构建通过；73 项任务运行测试、45 项组件测试、23 个崩溃诊断测试套件，以及工作项持久化、阶段产物和缓存回归通过。
• 200 文件、256 次突发进度更新合并为一次发布；快照隔离、并发更新、即时提交、检查点及退出补存均有覆盖。
• 59 项真实 Electron 验收全部通过，覆盖 1024/1440 宽度、滚动至末尾、删除撤销，以及实际终止渲染进程后的当前项目恢复；200 文件列表最多挂载 16 行。

范围

Linux 转储已确认 Chromium 共享内存句柄校验触发致命检查，但句柄为何异常仍未确定。本次处理有源码证据的性能负担及白屏后的恢复途径，仍需原 Linux 环境回归确认白屏和卡顿的改善程度。

Related to #574