4K 自动升档：从「升上去就掉下来」到「稳得住」 —— 这一版把降档的判据重做了一遍，并修掉了
4K 一直上不去的那道门。
变更
- 降档从此以「缓冲时长」为强制标准（P11-237、P11-239、P11-241）。此前有一条降档通道完全不看
缓冲：只要 20 秒窗口的带宽估计跌破当前档门槛，哪怕缓冲有 30 秒、而且还在涨，也会被降档，
还连带把这一档封 90 秒。真机实测过这样一枪：缓冲 30s、持续带宽 33Mbps，却被 20 秒窗口的
19.3Mbps打回了 1440p，而同一批数据算下来是「交付 29.7Mbps 对需求 24.8Mbps」。现在改为：
缓冲够（≥ 本档水位线）就不降档，只有水位真的跌破才由水位急救接管。 - 4K 的水位线撤回 20 秒、与所有档统一（8 秒）（P11-239）。20 秒这条线是常量，而「补货线」是按
往返耗时算的（11~17 秒）——只要往返快于 11.3 秒，20 秒线就永远在补货线之上，于是 4K 的缓冲
每个补货周期都会穿过它一次，而判据恰好只在缓冲最低点被评估 ⇒ 每个周期都判一次「饿」。
同一场、同一台机器的对照：1440p 的缓冲低谷 11.5 秒（在 8 秒线之上）全程零降档；2160p 的低谷
10.9 秒（在 20 秒线之下）升上去 13 秒就被降回。 - 修掉「4K 自动永远升不上去，只能手切」（P11-244）。低档在升上去之前，有一条现成的通道会把
下一档的数据提前取回来（预取），顺带把这一档的实测码率测出来；而顶档被这道通道自己的门槛
挡住了——旧门槛要求「声明码率 ≤ 实测带宽 × 0.8」，也就是「已经买得起才许预取」，比升档门槛
本身还严 14%。结果是 4K 从来没有被预取过、实测码率恒为 0，档位需求只能退回虚高 1.3~1.5 倍的
声明值（VBR 峰值），两道测量门槛就都按假数据立着。现在：门槛放宽到 1.5 倍口径，并且一次
失败不再等于本场放弃（此前评估失败仍会被登记为「已预取」，从此再不重试，而且不留日志）。
已知
- 真机已验证（dev.r2188，同一视频
DwWwXEeiumg，网络余量只有约 1.3 倍的中等场次）：
顶档第一次被预取（prefetch: 候选档 itag315，改前 0 次）⇒ 4K 的实测码率从恒 0 变成
23.9~25.4Mbps，声明虚高从 1.3~1.5 倍降到 1.0 倍；4K 自动上屏并稳住，期间带宽估计
一度跌到 19.4Mbps（低于 4K 门槛 21.3Mbps）——est-hysteresis downgrade held首次开火把
它拦住（缓冲 12 秒 ≥ 8 秒线），到日志尾仍在 4K、缓冲 18.3 秒，零降档、零卡死、零冷却。 - P11-244 的效果依赖一个前提：预取是「搭下一笔请求的顺风车」送出的，缓冲满时可能隔几十秒才发出。
所以它把「不可能」变成「可行」，不保证顶档在升档前一定拿到实测（本次拿到了，但依赖时机）；
若某些场次仍拿不到，下一步给预取一条独立通道。 - 一笔主动放弃的请求会砸塌带宽估计（上一轮判读发现、本次未处理）：缓冲偏低时 fetcher 会主动
把等待上限压到 8 秒，一次这样的超时会往 20 秒窗口里塞一个「零字节、8 秒」的样本，把估计从
28Mbps 拽到 14.3Mbps——而同一瞬间视频段其实是正常入队的。低档碰到这笔不受影响（它们门槛低），
但对 4K 是致命的。留给后续处理。 - 顶档此后独有的差别只剩「冲顶失败后二次升档的坎」：失败后该档封 180 秒、降档后须缓冲 ≥30 秒
才许再升、持续带宽须 ≥ 声明 × 1.1、升档垫子 20 秒。 - alpha.16 的已知项仍未变。