[BUG] Desktop file viewer serves a stale cached copy of an already-open file; edits only appear after navigating away and back

What happens

With a file open in the desktop app's file viewer, external edits to that file on disk are not reflected in the open view. The viewer continues to show a snapshot from when the document was last navigated to. Clicking to a different document and back re-reads the file and shows current content.

This is easy to miss, because the view looks normal — there is no staleness indicator and no reload affordance. The user believes they are reading the current file.

Why it matters beyond the refresh

Agent workflows increasingly write to a file and then link the user to it for review. If the user already has that file open, the link lands them on a cached version that does not contain what was just written. The failure is silent in both directions: the user may not find content that exists, or may review and approve content that has since changed. In a long document the natural conclusion is that they simply missed it while scrolling.

Steps to reproduce

1. Open a markdown file in the desktop app's file viewer.
2. With the view still open, modify that file on disk (an agent edit or an external editor both work).
3. Look at the still-open view without navigating away.

Expected: the view reflects the file on disk, or indicates it is out of date.
Actual: the view shows the previous content, indefinitely.

1. Click to another document, then back. The content is now current — which rules out filesystem sync lag as the cause.

Environment

Desktop app on Windows 11, version 2.1.219–2.1.220. Observed with a large markdown file (~460 lines) inside a cloud-synced folder; the navigate-away-and-back behaviour distinguishes this from sync lag.