[Studio Recorder] Long recording sessions have delayed updates, screenshot degradation, and slow finalization

What problem does this feature solve?

在 Studio Recorder 录制场景中，随着操作次数和截图数量增加，录制链路会逐渐出现响应延迟、截图异常和处理时间过长等问题，影响录制结果的完整性与可用性。

What does the proposed API look like?

问题表现

复现步骤

1. 启动 Studio 并连接目标设备或页面。
2. 开始录制。
3. 连续执行至少 25～30 次可区分的点击或输入操作。
4. 观察预览画面、Timeline 更新时间及每一步的截图和描述。
5. 在 Timeline 尚未完全更新时点击 Stop。
6. 完成 Generate 后点击 Download。

实际结果

• Timeline 无法随操作实时更新。
• 部分步骤的截图与操作时预览不匹配。
• 长录制后可能只保留点击坐标，不再生成具体元素描述。
• Stop 需要等待较长时间才能完成。
• Download 在保存对话框出现前没有明确反馈。

预期结果

• 每次操作都能及时出现在 Timeline 中，并显示当前处理状态。
• 操作步骤与操作时的预览截图准确对应。
• 长录制过程中步骤和元素描述保持完整；发生降级时明确提示原因。
• Stop 可以快速结束录制，剩余处理在后台可见地完成。
• Download 点击后立即显示导出状态和进度。

原因分析

上述表现来自同一录制链路中的多项累积问题：

1. Recorder 事件严格串行处理，每个操作还需要等待截图和页面状态采集，连续操作会形成队列积压。
2. Studio 每 500ms 轮询一次事件，进一步放大 Timeline 延迟。
3. 操作与预览截图没有稳定的事务绑定，截图采集时点可能晚于实际操作。
4. 单 Session 截图资产上限为 128MiB，高分辨率截图可能在约 20～25 次操作后触顶，导致后续语义描述退化。
5. Generate 和 Download 默认最多使用 20 张截图，超出部分会被静默裁剪。
6. Stop 会串联等待截图队列、事件拉取、AI 描述、持久化和元数据生成。
7. Download 在 Renderer 中串行读取截图并生成完整 Base64 ZIP，完成后才打开保存对话框。

Start by tracing the Studio Recorder flow through Recorder event handling, Studio's 500ms polling, Generate, and the Renderer Download path described in the issue. Reproduce a 25–30-action session and observe timeline updates, screenshot binding, Stop, Generate, and Download behavior. Done means these stages remain responsive, preserve complete and correctly matched steps, and visibly report processing progress.