fix(recents): merge the recent-files list instead of overwriting it

[PathGao]

First of a five-PR chain over MarkdownViewer.svelte. Each is independently reviewable; they are chained because they share that file. Merge order 1 → 5.

The defect

Three call sites — saveRecentFile, deleteRecentFile, and the rename sync — each did JSON.stringify(recentFiles) from the window's own in-memory copy. No re-read, no storage listener. With two windows open, the last one to touch the list silently discarded whatever the other had recorded.

The fix reuses #370 rather than inventing a second mechanism

This is the same shape #370 already solved for settings, so:

• New src/lib/utils/recentFiles.ts holds the pure list transforms plus updateStoredRecentFiles(mutate) — re-read, apply, write.
• The write goes through fix(settings): persist each setting on its own key and sync across windows #370's writeStoredSetting, which is compare-and-set. A no-op write fires no storage event, so propagation terminates after one hop. fix(settings): persist each setting on its own key and sync across windows #370's reasoning for why an isApplyingRemote flag cannot work applies here unchanged, and is cited rather than restated.
• A storage listener in the viewer folds in what sibling windows record.

No change to settings.svelte.ts was needed — writeStoredSetting was already exported.

Tests

scripts/recentFilesMultiWindow.test.ts — the concurrency tests drive two simulated windows against one shared localStorage and run the real merge, rather than asserting on source text.

Module absent (true master state)	suite fails to load
Module present, viewer wiring reverted	3 red / 9 green
Final	12 / 12

npm run check   0 errors
npm test        433 / 433
cargo test      131 / 131   (untouched)

Not covered

• Two windows writing in the same tick. localStorage is synchronous per document, so writes are serialised per webview; not tested.
• Paths differing only by case are treated as distinct entries.

🤖 Generated with Claude Code

[PathGao]

Reopening from an in-repo branch so the five-part chain can be a real stack — GitHub cannot use a fork branch as a base ref. Same commit, no content change.