4K 改成「全自动」：不用再手切 —— 一版修掉两个各自独立的坑：一个让视频连续重载，
一个让 4K 永远升不上去。
变更
- 「连续重载」的真因（P11-250）：切档时音频段被灌进了视频字节。日志证据很直接——音频段
正常是 60KB，出问题那一刻变成 2.4MB，播放器解析到这块假音频当场报错
（Skipping atom with length > 2147483647）→ 整场重载 → 重载后又爬档又炸，看着就是「连续重载」。
根因在取流层：服务端给每段媒体编的临时编号（headerId）每笔响应都会从 0 重新排，
而我们把它记在了一张跟着会话活的表里。以前响应是整包读完的，每段都能对上号，所以撞不上；
上一版之前改成「边收边用、拿够就停」之后，被截断的响应会留下没有收尾的段，
下一笔响应里被跳过的格式恰好复用同一个编号 ⇒ 那些视频字节就被追加进了残留的音频段里。
修法是把这张表降级成每笔响应自己的一份（响应结束即作废），顺带按参考实现补上一道
「实收字节必须等于声明长度」的校验当告警器。 - 4K 永远升不上去的真因（P11-251）：两个「20 秒」互相顶死了。升 4K 要求缓冲垫到 20 秒，
而 1440p 及以上又有一条「缓冲到 20 秒就停止预取」的上限——两条同值，而 1440p 正好是上限生效的
最低档 ⇒ 停在 1440p 时缓冲被压在 19.9 秒，永远差那 0.1 秒，连带宽判据都没机会评。而且这条
上限只停预取、不抽缓冲，排空靠播放 ⇒ 从低档带上来的高水位大约 20 秒就被消费掉，
这 20 秒成了升 4K 的唯一窗口，窗口内条件凑齐就升、错过就永久按死（真机两场差的就是这个：
一场 5 秒就凑齐、一场 22 秒才凑齐）。修法：升档垫子全档统一为「15 秒 与 两次本档往返取大」，
顶档不再单独加 20 秒。这不是放松要求——4K 真正的守门员是另三条、一字未动：持续带宽须
≥ 该档实需 ×1.1、起播卡顿后 3 分钟内不爬顶档、以及顶档不做「满缓冲试探」。
已验证（真机）
- 电视（BRAVIA AE2）：同一支视频全自动跑通 —— 720p → 1080p → 1440p → 2160p，
video size: 3840x2160上屏，之后sel=0稳定 2 分 24 秒以上，零降档、零卡死、零重载。
升档那一刻缓冲只有 19.9 秒（按旧口径正是被按死的数值）。 - 重载那条：同一场里
auto-retry、残留编号告警、长度不符告警、被跳过的格式——全部为 0；
整场只有一个取流会话，四条会话回收全部发生在退出播放器那一刻。 - 顺带验到：持续带宽闸先拒绝了一次（24.0Mbps < 门槛 30.9Mbps，因为该档此时只有声明值可用），
拿到实测锚后门槛降到 26.1Mbps、实测 33.6Mbps 才放行 —— 说明守门员是真在工作，不是被绕过去。
已知
- 白名单与预取仍然自相矛盾（未做）：升档时会向服务端点名要候选档，收到后又判成「未请求的格式」
整段丢弃——花带宽买回来再扔，也一直在制造上面那个「被跳过的 header」。要做就得连同「预取窗口
可撤销」一起上（历史上出现过预取数据把正在播的段挤掉、25~33 秒零可用数据），需实测证据再动。 - 4K 升档的窗口机制仍在：地板不再是瓶颈，但持续带宽闸要先拿到「同编码族实测锚」才按真实量级
评估——锚到手慢的场次（本场 22 秒）依然要等。这一条本轮未改。 - 「升进 4K 后 10 秒内被水位急救降回」这个反例本场没出现，但只跑了 2 分 24 秒，更长场次待观察。
- v3.1.0-alpha.18 的已知项仍未变。