ArtPlayer/refactor/changes/2026-09-14-ENG-13-observation-window.md

# ENG-13 性能资源探针的最小观察时间

MOD-03在新的实际安装包上执行正式性能配对时，Firefox第一轮报告因一项candidate
资源观察只有349ms而失败。该项是第二组chapter的最后一次资源探针；原门槛要求
至少350ms，因此失败是有效的观察缺口，不能把它四舍五入成通过或覆盖原报告。
Chromium/WebKit同轮完成，仍有既有体积/计时review-required信号。

## 原因与修复范围

冻结BASE-06夹具在记录起始时钟后只执行一次原生setTimeout(350)，然后记录实际
performance.now差值。名义延时不等于该次记录一定已满350ms；现有证据不能进一步
区分计时量化和原生调度因素，不能据此断言Firefox存在特定计时器实现缺陷。

修改只在`scripts/performance-fixture.mjs`的当前适配层加入waitForObservation。
它按同一个实测时钟计算剩余时间，等待后重新核对，不足时继续等待剩余部分。
使用probe已有的原始定时器，不把观察器自身加入播放器待释放定时器列表；没有
改变库的清理动作。记录仍使用实际now()-waitStarted，保持超出的实测时间。

`refactor/fixtures/performance.js`、旧JSON、所有计时阈值及350ms校验均不修改。
适配层对旧、新两个播放器使用相同处理；构造/ready/play/destroy计时循环、媒体、
热身、样本数量和交替顺序不变。变化仅限计时采样之外的销毁后资源观察窗口及
原有结果传输替换，测试逐字反向恢复冻结源来保护这个边界。

## 验证

- 原报告保留：`run-firefox-ERtLa6/report.json`，observedMs=349，校验明确失败；
  原Chromium/WebKit报告也保留，不把本轮重测覆盖到它们。
- 虚拟单调时钟覆盖首次349ms后补1ms、原生超出到364ms时保留实测值、已经满足
  时不再等待，以及定时器拒绝原样传播。原349ms候选报告变体仍须被校验器拒绝。
- 适配层测试证明去掉结果传输和最小观察适配后，内容与冻结文件完全一致。
- 使用同一`run-rawoRh`实际安装的core/chapter产物重新执行三引擎完整三组配对。
  包的源文件、构建工具和安装字节由现有严格验证器核对；该补丁不改变包内容。

最终9项测试通过（含冻结发布性能/压缩基线），定向lint、严格工具链、计划及风险
校验通过。原生三引擎三项完整配对测试通过，共108个旧新资源窗口，54个候选窗口
均通过严格清理检查。最短实际观察为Chromium350.2000000476837ms、Firefox350ms、
WebKit350ms；没有取整或使用名义延时代替真实值。第二轮没有计时reviewSignals，
但首轮Chromium销毁计时信号仍保留，不能把样本波动当作本补丁带来的计时收益。
三引擎均因原有分发体积信号保持review-required。

具体最终结果、环境、来源指纹、原失败和修复后报告见
[机器证据](../baselines/observation-window-validation.json)。该任务只处理观察窗口
可靠性，不能把review-required变成性能发布通过；MOD-03及ENG-PERF-01/02继续。
也不表示所有插件、物理设备、远端CI或最终候选发布完成。无新依赖或API改动。

回退本任务提交即可恢复旧适配器；不要回写冻结夹具或放宽350ms断言。原失败应
继续保留。完成后独立本地提交；不push/publish。