fix: re-file the Quarto output cache when an untitled document is saved in web

[midleman]

Summary

When you run a Quarto cell, Positron saves a copy of the output to a cache filed under the document's address. Saving an untitled document with Save As is supposed to re-file that cache under the new filename, but the code only did so when the new address looked like a plain local file. In Positron Web and remote sessions a saved file has a different kind of address, so the cache stayed filed under "Untitled-1" and a window reload found nothing to restore, so the output vanished.

• Re-file the cache for any saved address, not just plain local files
• The output looked fine right after the save because a copy in memory was matched by cell content; only a reload exposed the loss
• Explains why this failed on web (71% on sles/chromium) but almost never on desktop, where a saved file does have a plain local address
• One thing to flag for review: when a cached cell matches no cell in the saved document, the untitled cache is cleared anyway, so a cell edited during the save loses its output. The new test pins that behavior; making the clear conditional would be a separate change
• Adds quartoOutputManagerSaveAs.vitest.ts covering the re-filing for a remote address, a local file, and untitled-to-untitled

Release Notes

New Features

• N/A

Bug Fixes

• Quarto inline output no longer disappears after reloading the window when an untitled document was saved with Save As

Validation Steps

@:quarto @:web @:win

1. Open a new untitled Quarto document, add a Python cell, and run it
2. Save As to a real filename, then reload the window
3. The cell's output should still be there

E2E Triage Diagnosis

🟢 High confidence -- CORRECTED (supersedes the parse-race summary below): on Save As the Quarto output cache is never rebound from the untitled URI to the saved document, because _transferCacheFromUntitled is gated on this._documentUri.scheme === (file) (quartoOutputManager.ts:391) and in web a saved document URI is vscode-remote. The post-save assertion still passes via the in-memory findCacheByContentHash fallback to the live untitled cache; that fallback cannot survive a window reload, so post-reload restore finds no cache under the saved URI and mints zero view zones.

• Test: Quarto - Inline Output: Persistence > Python - Verify inline output works in untitled Quarto document and persists through save
• Targeted failure: Pattern A -- expect(locator).toBeVisible() on locator('.quarto-inline-output').first().locator('.quarto-output-content'), 5 occurrences / 71.4% of 7 runs on main, sles/chromium, rep sha dea62542943085c854378d6c4132f800c0c5a1ba (run 30889748402).
• Signal: VERBOSE=1 e2e-chromium run (renderer trace + console forwarded to e2e-test-runner.log), repeat1 failing at spec line 92: 19:22:39.886 Saved output for cell 0-c2a393fb-unlabeled in untitled:Untitled-1; 19:22:40.719 Initializing for vscode-remote://.../test-...qmd (Save As -> vscode-remote scheme, so no Transferring cache from untitled to file line ever appears); 19:22:40.777 No cache file found for vscode-remote://...; 19:22:40.780 Found matching untitled cache: untitled:Untitled-1 with 1 matching cells -> Found cache by content hash match -> Restored cached outputs for 1 cells (this is what makes the post-save assert pass); 19:22:43.75 Flushing all caches / Flush complete; after reload 19:22:46.16 Initializing for the saved URI -> 19:22:46.399 No cache file found -> 19:22:46.541 No cached outputs to restore, with no untitled-cache match this time. Environment skew confirmed by mechanism: desktop saves to a file-scheme URI so the transfer runs (0.8% on win/electron) while web never does (71.4% on sles/chromium).
• Frequency: 5/7 runs (71.4%) on main, sles/chromium
• Hypothesis: Dropping the file-scheme requirement on the untitled->saved transition (accept any non-untitled scheme) makes the transfer write the cache under the real saved URI, so the post-reload restore finds it. The fix(quarto): restore inline output on close+reopen before parse #15091 deferral fix is a genuine but separate bug: its log lines (No cells parsed yet, waiting for parse to retry cache load -> Cells found after parse, retrying cache load, 19:22:37) show it running as designed on the untitled document without affecting this failure. Ruled out: lost debounced write (the cache service joins flushAll on onWillShutdown and Flush complete is logged before the reload); _transferCacheFromUntitled losing a parse race (it is never called at all -- no transfer log line); the deferral gate (fix present and exercised, e2e rate unchanged: pre-fix 1/3, post-fix 4/6, verbose 4/4).
• Supersedes: PR fix(quarto): restore inline output on close+reopen before parse #15091 (closed unmerged 2026-07-23, same mechanism, first found via the dataframe close+reopen flake)

[github-actions]

E2E Tests 🚀
This PR will run tests tagged with: @:critical @:quarto @:web @:win

Why these tags?

Tag	Source
@:critical	Always runs (required)
@:quarto	PR description
@:web	PR description
@:win	PR description

More on automatic tags from changed files.

^{readme  valid tags}

[jmcphers]

Looks good!