fix(preview): a theme change re-draws the diagrams it has never re-drawn (#741), retargeted to master

[PathGao]

Base is master. Administrative: this is #741, already reviewed and merged,
but into perf/rich-content-anchor-drift rather than into master, because that
branch was its base while #740 was open. #740 was squash-merged to master,
which closed the branch's own PR and left this sitting where nothing points at
it. Cherry-picked onto master; the commit below is the same one. Same thing
happened to #732-#735 earlier in this series (#737).

Rebasing the branch instead does not work: #740's own commit conflicts against
its squash on master, which is the same content under a different SHA.

What is in here

A theme change never re-drew a Mermaid diagram, in any mode, for any theme, and
had not since #632.

renderRichContent finds diagrams with selfAndDescendants(root, 'pre code'),
and a diagram that has been drawn once has no <pre> left — that same function
replaced it with <div class="mermaid-diagram">. While the preview was
{@html sanitizedHtml} this was invisible, because every render put the whole
document back as source and the diagram was rebuilt from scratch. blockPatch.ts
keeps the enriched nodes instead, so from #632 on the theme change reached
nothing. Mermaid bakes its colours into the SVG, so a dark diagram stayed dark on
a light page indefinitely.

The source was already on the container — mermaidPrint.ts keeps it there so the
PDF path can rebuild the diagram light — so the theme it was drawn for is kept
beside it, and renderRichContent now collects the containers whose theme no
longer matches and re-draws them through a drawDiagram both paths share. The
collection runs before the pre code loop so the containers that loop is about
to build are not scanned as stale.

The viewer's theme effect also stopped depending on isEditing. It was a tracked
read, so every ⌘E and every mode-changing tab switch re-ran the whole theme block
— dataset writes, clearVscodeTheme, saveStartupAppearance,
monaco.editor.setTheme, and for a vscode: theme an invoke('read_vscode_theme')
round trip plus a re-parse — to draw no diagram at all. git log -S puts that
guard at 06380bc, where enrichment was a whole-document pass on every render and
the preview was hidden in edit mode: it was protecting something real then. Its
sibling lost the guard when the patch effect was built; this copy was never
revisited.

Measured in Chromium over the real pipeline, one whole-article pass with the
other memos warm, two runs:

                             diagrams   theme moved   theme unchanged
samples/katex-stress.md            0    8.6-10.6ms       11.9-12.2ms
samples/markdown-syntax.md         4   61.2-76.1ms         2.6-3.0ms
samples/stress-test.md             3  107.5-121.2ms      12.5-12.8ms

The diagrams are the whole cost; katex-stress has none and its two columns agree.
The right-hand column is what a mode toggle used to pay to draw nothing.

Tests

scripts/diagramThemeRefresh.spec.ts drives renderRichContent twice against a
recording Mermaid stand-in — a behaviour test, not a source assertion. Reverting
the re-draw with the tests kept turns 4 of its 5 red.

Two assertions from #740 went red on this change and were updated rather than
relaxed: mermaidPrintTheme.test.ts pinned rememberDiagramSource's arity and
previewAnchorRestore.test.ts pinned a whole guard line when what it is for is
the untrack. That is the "pins today's spelling" weakness #740's own body
called out, arriving one PR later.

Verification

npm audit            0 vulnerabilities
npm run check        828 files, 0 errors, 0 warnings
npm test             1022 pass, 0 fail
npm run test:vitest  434 pass, 0 fail
cargo test           164 pass, 0 fail

Re-run after the cherry-pick. The app cannot be run here: worth toggling
light/dark with a document containing a Mermaid diagram open before this lands.