[harsh-thakkar7]

Summary

Ctrl+S could mark unsaved edits as saved, losing them silently.

Root cause

saveFile() snapshotted the content, awaited an HTTP round trip, then cleared
dirty unconditionally:

await Files.write(path, activeTab.content);
updateTab(activeTabId, {
  dirty: false,          // <- cleared regardless of what happened during the write
  filePath: path,
  ...
});

activeTab.content is read synchronously at the call site, but dirty is
cleared after the await, with no check that the buffer still holds what was
written.

Files.write is a real network call:

write: (path, content) =>
  apiFetch(`/api/files/write`, { method: "POST", body: JSON.stringify({ path, content }) }),

against the backend's /api/files/write. So the window is a genuine round trip,
longest for large files.

Effect

1. Open a large Markdown file, so the write takes a noticeable round trip.
2. Type, press Ctrl+S, and keep typing while the write is in flight.
3. The write completes and dirty: false is applied.

The disk holds the pre-save text, but:

• the blue ● in TabBar.tsx disappears
• StatusBar stops reporting unsaved changes
• there is no unsaved-changes prompt on tab close, so nothing warns you

The extra words are unrecoverable.

The same inversion applies to a deletion during the window — comparing
lengths or a flag would miss it, so the comparison is on the whole buffer.

Changes

frontend/src/lib/save-settle.mjs (new) — settleSavedTab() holds the rule in a
plain ESM module so the Node suite can exercise the exact code the app runs
(same pattern as http-timeout.mjs):

export function settleSavedTab({ writtenContent, currentContent, savedPath }) {
  return {
    // Equal means the buffer still holds exactly what reached disk, so the
    // document is saved. Any difference means edits are still unsaved.
    dirty: currentContent !== writtenContent,
    filePath: savedPath,
    label: fileNameOf(savedPath),
    previewBaseDir: dirOf(savedPath),
  };
}

frontend/src/hooks/useEditor.ts — both save paths (known path, and Save-As via
the native dialog) now:

• snapshot writtenContent before the call
• apply the patch through a setTabs updater, so currentContent is read from
  the latest state rather than the value captured before the await

The path and label are still adopted either way, so tab identity behaviour is
unchanged. Only dirty becomes conditional.

Two follow-on changes

updateTab is removed. It existed for exactly these two call sites, and both
are now setTabs updaters, so it became dead — an assigned-but-never-read
warning rather than something worth keeping for a hypothetical future caller.

previewBaseDir moves into the helper. Saving under a new name moves the
document, so its relative image paths then belong to the destination folder
rather than the one they were authored in. That was previewBaseDir: parentDirOf(path) inlined at both call sites; it is now part of the settled
patch, so the rule stays covered by the Node suite instead of sitting untested
in TypeScript where a future conflict resolution can silently drop it.

Testing

frontend/tests/save-settle.test.mjs, 12 cases:

• no intervening edits → dirty: false
• text typed during the write → stays dirty, but still adopts the path
• a deletion during the write → stays dirty
• two different buffers of equal length are not confused
• an empty buffer saved as empty is clean
• Save-As to a new path still renames the tab
• fileNameOf for POSIX and Windows separators
• a save re-points previewBaseDir at the destination folder
• previewBaseDir follows the save even when edits are still unsaved
• a Windows save yields a Windows base directory
• dirOf for both separators, and for a path with no directory component

6 of 6 mutants killed, including the two that would have reintroduced the
merged-from-#313 behaviour: "never updates previewBaseDir" and "only updates it
when clean".

Worth noting: the first draft of the helper compared in the wrong direction
(dirty: written === current), and these tests caught it immediately — 6 failed
rather than passing silently. The previewBaseDir cases went the same way: a
first draft closed the converted tab instead of the plain one, so it asserted
the wrong tab's folder and passed under a mutation that deleted the field.

Verification

• npm test — 61 passed (49 on main; this PR adds 12)
• npm run lint — clean, no warnings
• npm run build — clean
• backend pytest — unchanged

[petertzy]

Approved. This PR fixes a genuine data-loss race during asynchronous saves. It snapshots the content sent to disk and compares it with the latest editor buffer after the write completes, ensuring that edits or deletions made during the request remain marked as unsaved. The fix applies to both regular Save and Save As, while preserving the saved path, filename, and preview base directory. The added regression tests cover unchanged content, edits, deletions, equal-length buffers, empty files, Save As, and POSIX/Windows paths. All 61 frontend tests pass, so this change is necessary and ready to merge.