feat(viewer): make large traces lazy, safe to inspect, and explainable

[fengjikui]

背景

PMA 可以捕获并查看完整 Agent Trace；但当 Codex 等 Harness 的长会话经历多次上下文压缩、包含图片或大工具输出时，单条 Trace 可能达到 GB 级。若 Viewer 一次性解析并渲染 Raw JSON、Base64、超长文本或大型数组，页面会明显卡顿，甚至无法有效检查问题根因。

这不是只发生在异常会话中的边缘问题：PMA 本身正是用户观察上下文、压缩与 Harness 行为的工具，因此应能安全地打开并解释“大 Trace”。

关联的上游现象已在 Codex 报告：openai/codex#33493。

目标

让 PMA 对巨大 Trace 保持可用，并把它从“原始日志浏览器”提升为“上下文膨胀诊断工具”。

期望行为

1. Raw 详情惰性加载

• 不在首屏解析或渲染全部 Raw 内容。
• 按请求、区块和详情面板按需加载。
• 长列表使用虚拟化渲染；大型 JSON 的格式化与索引放到服务端或 Worker，避免阻塞主线程。
• 默认仅展示安全摘要，用户显式操作后才加载对应原文。

2. 大负载的安全占位

对以下内容默认不内联渲染：

• 图片 / data URL / Base64
• 超长字符串
• 大型 JSON 数组或嵌套对象
• 可能包含敏感数据的原始载荷

占位应至少显示：

• 内容类型与 MIME type
• 字节数、估算 token 数
• 图片尺寸（可得时）
• 内容哈希或稳定引用
• “加载原始载荷”这一显式操作

3. Trace 体积归因

在 Trace / 请求 / 上下文压缩层级提供可折叠的统计：

• 主要体积来源：文本、图片、工具结果、推理、元数据等
• 本轮新增量与累计量
• 压缩后仍被保留的内容分类
• 重复载荷 / 同哈希内容的次数与估算体积
• 对大文件、高保留率、接近上下文阈值的告警

4. 诊断视图

增加一个轻量的“Context / Size”诊断入口，帮助回答：

• 当前上下文为何仍然很大？
• 最近一次压缩保留了哪些类别？
• 哪些历史图片、工具结果或消息重复出现？
• 哪个请求或区块最值得先查看？

非目标

• 不在 PMA 中默认删除或修改用户原始捕获。
• 不以降低取证完整性为代价隐藏数据；完整原文仍应在用户明确请求后可查看。
• 不向外部服务上传捕获内容。

验收建议

• 使用含多张内联图片与大工具结果的合成 Trace，首屏可快速打开且主线程无长时间阻塞。
• 在未点击“加载原始载荷”前，Raw 视图不创建完整 Base64 / 大 JSON 的 DOM 文本节点。
• 用户可以定位到最大的保留项、重复项及其来源请求。
• 小型 Trace 的现有查看体验不退化。

隐私

本 Issue 不附带真实 Trace、提示词、源代码、路径、截图或凭据。后续测试应使用合成或严格脱敏的 fixtures。