Large-paste jank is textarea layout, not the diff path: consider wrap=off or an input preview swap #17

Found during M10 (issue #16). With compute in a worker and rendering virtualized, the one remaining main-thread stall on large inputs is the browser laying out the input textareas themselves: setting a 120k-line (3.4 MB) value into one of the design's soft-wrapped textareas costs about 2.1 s of forced layout in headless Chromium on the dev machine (measured stage by stage; the diff path in the same probe: 339 ms compute, which runs in the worker, 29 ms row model build, 0.4 ms for a 100-row window).

This cost predates M10, is proportional to input size, and is native to holding the text in a soft-wrapped <textarea>. The M10 responsiveness check (scripts/check-virtual.mjs) measures and reports it separately so it cannot mask a diff-path regression, but it cannot fix it.

Options, all design-affecting and therefore Alex's call:

• wrap="off" on the textareas (layout gets much cheaper; changes wrapping behavior visibly)
• swap the textarea for a read-only summary above a size threshold (keeps the text out of layout entirely; changes the editing story for large inputs)
• accept the one-off stall as the cost of an editable input and document it

No change shipped in M10 beyond measurement and disclosure.