fix: keep block gutters only for the blocks in view

[Azganoth]

Summary

Every edit rebuilt a gutter for every selectable block and positioned each one by reading the block's layout right after writing the previous gutter's styles, so a keystroke forced one document layout per block. A node decoration on every block also rewrote a position attribute on each block after the edit and built its decoration set at a cost of blocks times decorations. Typing therefore slowed with the square of the document's size: 3.4 s per character at 500 KB.

• Gutters now exist only for blocks in the document view. Blocks start in document order, so the first block starting in view is found by bisection; the only blocks above it that can reach into view are its predecessor and that block's ancestors, so a list item or blockquote straddling the top edge keeps its gutter. Folded blocks have no layout and are passed over. Scrolling adds and drops gutters, reusing a gutter while its block stays in view.
• A positioning pass reads all block geometry, the surface, and computed styles before writing anything, then reads the gutter rects once. A keystroke now forces a fixed number of layouts however long the document is.
• Only selected blocks carry a decoration. Blocks no longer carry data-leafdown-block-pos; hover and drop find their block through a map of the elements in view, and the gutter and handle keep the position. Only the blocks in view are watched for resizing, and the selectable-block traversal is computed once per document state.
• Gutter selection, hover, insertion, clipping to the document view (Block controls render outside the editor card #657), and inertness under open menus (Insertion gutter reacts to pointer input through open menus #658) keep their behavior. A block wholly outside the view now has no gutter where before it had a hidden one, which nothing could reach.

The E2E specs used the removed block attribute to pair a handle with its block. They now read the position from ProseMirror's pmViewDesc on the rendered element, an internal that is stable but undocumented. The block-selection fixture is taller than the E2E window, so its last three list items have no gutter at the default size: getGeometryForText scrolls a block into view before reading its handle, list-item counts and order come from the document, and the list-item spacing check measures the items directly.

Related Issue

Closes #670

Verification

• pnpm exec vitest run src/features/editor/plugins/blockSelectionInteraction.test.ts: a gutter appears as its block scrolls into view and is dropped once it leaves; a container reaching into view from above keeps a gutter fitted to its visible part while a child above the view has none; an edit to a 400-block document with a folded section reads a bounded number of block rects, rebuilds only the gutters in view, and leaves no decoration on any block. These tests fail against the previous plugin. The clipping test now expects no gutter, rather than a hidden one, for blocks wholly outside the view.
• pnpm check:frontend passed.

Manually verified in an isolated Windows 11 release build driven over the WebView2 DevTools protocol, with documents built by concatenating README.md, CONTRIBUTING.md, docs/*.md, and docs/help/*.md to each size. Keystroke time is from key down to the next paint after typing at the end of a paragraph near the middle, the median of five keystrokes on this branch and three on main; layouts are counted in a trace of one keystroke; open time is from choosing the recent file to the end of the last long frame, one open each. Same session, same machine:

	main (7cea7b9)	This branch
500 KB keystroke	3,408 ms	72 ms
500 KB layouts per keystroke	2,735	4
500 KB open	5.3 s	4.3 s
1 MB keystroke	18,104 ms	80 ms
1 MB layouts per keystroke	5,825	4
1 MB open	20.3 s	7.8 s
1 MB page elements	45,061	21,813

1. In the same build, the block-selection E2E fixture showed gutters only for the blocks in view at 800×600, 640×720, and 640×400.

Not verified: the desktop E2E specs were adapted without running them locally; CI runs them.

Notes

About 200 ms after each keystroke, a 270–580 ms frame remains at 500 KB. It is the debounced whole-document serialization, with no forced layout, which #672 covers. Opening 1 MB still exceeds the 3 s budget #638 proposes, and the gutters no longer account for that time.