[Bug]: Severe input lag on a large (127 kB) document — both rendered and source views #24

No profiling data — this is a report of observed behavior only. The attached
document is synthetic, generated from random syllables, and contains no real
content.

Observation and suggestion: the delay appears to scale with the size of the
document rather than with the size of the edit, and it affects both editing
modes, which would be consistent with the whole document being rebuilt on every
keystroke instead of just the part that changed.

Reading the source, there is a whole-document code path on each side:

- Rendered view: emitChange() in editor.js calls serializeDocument(), which
  walks the entire article DOM and reassembles the full Markdown string, then
  calls refreshSplitSourcePositions(), which serializes every top-level block a
  second time and locates each one inside the full string — and that runs
  whether or not split view is in use.
- Source view: MarkdownSourceEditor.highlight() reapplies its regular
  expressions across the whole text on every change. Because WorkspaceView keeps
  both editors alive and only changes their frames, an edit made in the source
  pane also drives a full previewmdRender() of the entire document in the web
  view, even when the preview is not visible.

If that is the cause, caching and incremental work would help more than
micro-optimisation: keep the serialized form of each top-level block and
re-serialize only the block containing the edit; restrict highlighting to the
affected range; and skip work for a pane that is currently hidden. The
block-level source ranges needed for the first part already exist as
data-previewmd-source-start / data-previewmd-source-end.

Note on the environment: macOS 27 is a beta release, so I cannot rule out that
the OS contributes.