计时埋点与归因证据缺口
本任务没有添加运行时埋点；以下只说明未来要准确解释成本需要什么。不能用新增探针或重跑补充本轮原始证据。
| 缺口 | 本轮可知道 | 本轮不知道 / 应保留NA |
|---|---|---|
| Pair、Witness、Ledger、缓存CPU细分 | history_enumeration/evidence_build局部计时，prepare总墙钟 | 完整互斥细phase、CPU与worker排队拆分 |
| post_prepare到最终选择 | 精确混合总墙钟 | Probe查找、普通Remote Greedy/Epsilon各占多少 |
| Provider await精确起止 | await累计ns；WAIT_STARTED/CONSUMED包围 | 每分钟唯一精确物理分摊，因此输出上下界 |
| Gateway队列细分 | 同Host received/sent/completed，可区分发送前与上游 | 发送限速、并发限额、身份检查、DB等待各自耗时 |
| Provider上游内部 | HTTP调用外部墙钟 | 推理、服务内部队列、协议编码细分 |
| GUI执行与App加载 | 选择、输入回执、确认、页面类 | 页面实际就绪、动画、网络加载、GUI dump及注入各自耗时 |
| FUZZ内部 | 批次输入及低层事件列表、下一输入envelope | 每低层事件实际执行起止与精确FUZZ批末 |
| 崩溃恢复 | App异常stack、step、时间 | 统一恢复开始/完成；不能以异常次数×固定时间 |
| 后台回执写盘 | writer聚合总量/末尾样本 | 没有被主线程等待时不能当阻塞；不能把receipt/image/queue嵌套相加 |
| 反事实吞吐 | 同App三条件各自60分轨迹 | 相同动作/页面下取消审核可多执行多少动作 |
| 方法时间线 | METHOD首次观测并保留preformal/尾部 | 完整APK-wide方法逐个首次执行；未观测不能填0 |
| 平台发送限速实现快照 | 冻结配置+已落盘同Host时间+当前源码旁证 | 当时平台源码逐字节部署身份，不能伪称已冻结验证 |
JevReviewProfile.java定义若干phase，并不表示本轮每个phase都有实际输出；冻结源码中缺完整实例化/输出链。JevTiming聚合可能只保留最后2,048样本，不能当每Run所有事件原始分布。优先用逐审核计时；聚合项作为附加证据保留在native-performance-counters.csv。
接下来优先检查的具体位置
- Jev Gateway发送准入队列如何沿Native同步await占用探索预算。先保留原始队列/上游/await三时长，不以HTTP 200代替效率证明。
- Scarlet和Activity同版本State反复进入真实Pair/HTTP的阶段。关联候选身份、历史revision、缓存未命中、模型答复和Ledger结果；单靠入口数或卡片文本无法定性。
- Omni prepare后选择耗时，以及exact alarm/输入解析异常的恢复边界。现有数据不能确认哪一个函数最慢，不直接提议改某个算法。
以上不实施优化，不变更限速、Prompt、Provider、JAR或Probe。缺失数据在CSV使用NA；有实测0的事件（如Jev Activity崩溃回执0）与缺少恢复时长NA严格区分。