feat: Copy as Rich Text — the rendered document, ready to paste

[productengineered]

Export writes a file that carries its own stylesheet. A paste carries nothing — every destination throws away <style> blocks and class names — so the formatting has to ride on the elements. ⌥⌘C (File menu, next to Export; also ⌘K) puts the document on the clipboard as HTML with the styles inlined, and the markdown itself as the text/plain flavor.

What travels, and what deliberately doesn't

A paste target already knows what a heading, a list, a link, and bold text are, and it will style them like the rest of its own document — which is what anyone pasting wants, so those carry nothing (headings keep the Fraunces stack and no size). What it cannot infer is inlined: table hairlines and header fill, columns proportioned the way a drag-to-resize left them (<colgroup> from columnDisplayWidth, the same function the preview sizes with), the fence's tinted mono, the quote's fill, the rule, and Shiki's token colors resolved through their palette indirection to literals.

Every value comes from tokens.css + themes/ledger.css — parsed, var()s resolved (balanced-paren scan, nested references followed), never a hardcoded hex. Always the light palette, for the reason print gives in export.css: paper is paper even from a dark-mode machine, and a paste lands on someone else's white page.

Three things a destination would otherwise lose:

• Task checkboxes — <input type="checkbox" disabled> is inert markup most destinations drop, taking the done/not-done with it. It becomes ☐ / ☑, which is text and survives anything.
• Images — a relative src means nothing once pasted. Local images travel as data URIs (Docs and most CMSes accept and upload them) under an 8 MB budget, falling back to absolute file: URLs past it.
• Class names — stripped. They mean nothing without our stylesheet, and shiki or task-list-item landing in a CMS that styles those names would mean something wrong. Ids stay; footnote links are built on them.

Why it works on the rendered HTML rather than the tree: the highlighter's markup — the spans this has to recolor — exists only in the output string. A rehype plugin registered after rehypeShikiFromHighlighter still sees a bare <pre><code> (verified both ways, lazy on and off). So src/shared/markdown.ts is untouched, and the golden fixtures with it. The markup being rewritten is our own, from one generator, and the tag scan is quote-aware so a > in alt text can't end a tag early.

Tests: pnpm test 337 (28 new) / pnpm typecheck clean. Note the unit tests inject the palette read from the sheets on disk, because vitest stubs CSS imports away — a ?raw import arrives as '' there. That path is covered instead by a live check in an isolated instance: drive the palette entry, then read the clipboard's flavors back through the main process. 16 checks, all passing — both flavors present, the text flavor byte-identical to the source, no var( left anywhere (so the ?raw sheets did reach the packaged build), the colgroup proportioned 22.222/77.778 from the delimiter row, the fence recolored, checkboxes glyphed, the PNG embedded as a data URI. The driver saves the user's clipboard first and puts it back.

No package.json / version changes, per the usual.