fix(preview): serve fresh HTML for project pages after .qmd edit

[cderv]

When previewing a website or book project, editing a non-index .qmd regenerated the HTML on disk but the preview server kept serving the pre-edit body. Stopping and restarting quarto preview cleared it for the first edit; the next edit reproduced the bug.

Root Cause

watcher.project() returns a long-lived ProjectContext whose fileInformationCache.fullMarkdown caches the expanded markdown per input. The HTTP-handler render in src/project/serve/serve.ts reuses this context, so after a watcher-triggered re-render, projectResolveFullMarkdownForFile returned the pre-edit expanded markdown. The regenerated HTML body therefore reflected the previous content.

Fix

Two layers, motivated separately:

1. Surgical (src/project/serve/watch.ts): invalidate the project context's fileInformationCache for each changed input inside the submitRender callback. Inside the callback (not before submitRender) so the cache mutation is serialized with any in-flight HTTP-handler render via the existing render queue — invalidateForFile may delete a transient .quarto_ipynb, and running it before enqueue could race a concurrent read.
2. Defense-in-depth (src/project/project-shared.ts): guard the fullMarkdown cache entry by source file mtime + size. A stale entry is dropped on the next read even if a future caller forgets to invalidate. Size catches the case where filesystems with coarse mtime resolution (e.g. 2-second FAT/SMB) place a rapid edit in the same tick.

Scope

This PR fixes the direct symptom for non-index project pages where the edit is to the .qmd file itself. Related cases raised in the issue thread are not covered here and are tracked separately:

• Edits to files included by a page via {{< include >}} — the includer's cache is not invalidated when the includee changes (Preview not updated on changes to included files #2795).
• Edits to a template-partials: file (quarto preview does not re-render when a template-partial is edited #14561).
• Cross-reference propagation between sibling pages.

Test Plan

Automated (tests/unit/project/file-information-cache.test.ts): mtime guard, size guard, per-file invalidation.

Manual spec: tests/docs/manual/preview/10392-project-preview-stale-cache-after-edit.md.

• Edit a non-index .qmd in a website project — served HTML reflects the edit (T1)
• Repeat without restarting preview — second edit also reflects (T2)
• Edit index.qmd — no regression on the index path (T3)
• Concurrent saves on a Jupyter input — no file-not-found errors in preview console (T7, race regression)
• Single-file preview Jupyter regression — .quarto_ipynb accumulation tests pass

#11475 and #13755 report the same root cause on older release lines (1.6, 1.8); this PR addresses it on main for 1.10.

Fixes #10392
Fixes #11475
Fixes #13755

[posit-snyk-bot]

✅ Snyk checks have passed. No issues have been found so far.

Status	Scan Engine	Critical	High	Medium	Low	Total (0)
✅	Open Source Security	0	0	0	0	0 issues
✅	Licenses	0	0	0	0	0 issues

💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse.

[cderv]

Manual preview testing

I ran the manual preview protocols against this branch (dev build, Windows), focusing on the two surfaces the fix touches: the project-preview-only invalidateForFile call in watch.ts, and the mtime + size freshness guard in projectResolveFullMarkdownForFile that runs on every render / inspect / execute path. The protocols live in tests/docs/manual/preview/ (the 10392-… doc plus a blast-radius regression matrix) so they're repeatable.

Jupyter .qmd freshness + transient cleanup

Edited a Python cell in a website project mid-preview. The served HTML and _site/ both picked up the change on the next reload, and at most one *.quarto_ipynb existed during a render with none left at rest — no numbered _1/_2 variants.

Raw .ipynb input

Edited a markdown cell of a native .ipynb page in the project. Output refreshed and the source .ipynb was preserved — the watcher's invalidateForFile skips safeRemoveSync for non-transient targets, so a user notebook is never deleted by the new call site.

Concurrent saves during an in-flight render

Used a time.sleep(5) Python cell to widen the render window, then fired several sub-second saves while a render was in flight. No ENOENT / BadResource / "cannot read .quarto_ipynb" errors — invalidation runs inside the render queue, so a transient notebook isn't removed while a render is still reading it.

One thing I noticed while doing the burst test: under a sub-second save burst the watcher coalesces the saves into a single render, so the final body can reflect the first read of the burst rather than the last keystroke. That's render-scheduling behavior, separate from the cache fix here — single edits, and edits a second or more apart, always render fresh. I'm tracking it as a follow-up and it doesn't affect this change.