perf(messages): prepare a message once for its renderer and link previews - #3466

Problem

Link previews (#3219, #3225) find a message's preview URLs with previewLinks. For any body with an https:// link, that function called prepareMarkdown, then scanned the prepared content again with scanMarkdown, and kept no result. The renderer already prepares the same body through its own cache.

A link-bearing row therefore parsed its Markdown two or three more times than a row without links, on every mount. It did this again on each remount while scrolling or switching channels.

Change

• markdown-preparation.ts:
  • Owns the cache of recent prepared bodies. recentResults and preparedBodies move here from MessageMarkdown.tsx, unchanged.
  • Exposes it as preparedMarkdown(content, scanned?).
  • prepareMarkdown takes an optional scanned callback that receives the scan it made. It stays pure and keeps no state.
• MessageMarkdown.tsx reads through preparedMarkdown, with the same cache and budget as before.
• preview-links.ts:
  • Uses preparedMarkdown. On a fresh preparation it takes the scan through the callback instead of scanning again.
  • Keeps recent preview link lists in a recentResults cache. The key is the content and exclusions; the weight counts both the key and the URLs. Cached lists are frozen.
• preview-links.test.ts asserts that the renderer and previews together scan a body once. This fails on the previous code.

Why behaviour is unchanged

• prepareMarkdown is pure, so a cached prepared body is identical to a fresh one.
• The scan passed to the callback is the scan of the returned content, the same input previews scanned before.
• The link list depends only on content and exclusions, which are both in the cache key.

Evidence

Interleaved A/B on 9 Linux and 9 macOS boxes:

• 6 rounds × 2 samples per variant on each box, so n=108 per variant per OS.
• 4× CPU throttle.
• Values are the mean of per-box medians.

The baseline is main (7bb45482) with #3464 and #3465 applied. This change was measured on top of that. The measured revision handed the scan over through module state instead of a callback; the parse count is the same. A variant with preview scanning disabled entirely is the ceiling.

• Thread scroll open improved on every box (9/9) for script and LoAF on both OSes.
• The change recovers all the time that link-preview scanning costs in these scenarios.
• An earlier A/B of desktop-v0.7.18 against the same baseline put thread scroll open at +2.6% script on both OSes, which this removes.

Checks

• vitest run src/features/messages: 3119 pass.
• link-previews.spec and markdown-documents.spec pass on chromium and webkit.
• bin/pnpm check is clean.

🤖 Generated with Claude Code