fix: keep block gutter controls within the document view

[Azganoth]

Summary

Block handles, the insertion button, and the insertion line live on a window-wide fixed layer attached to the page body and are positioned from each block's raw client rect, so a block scrolled past the top or bottom of the document card painted its controls, and their pointer targets, over the surrounding app.

• The layer is clipped to the document's scrolled view, the same scrolling ancestor heading folding treats as the document surface, so any part of a control past the view's edges neither paints nor receives the pointer.
• Each gutter is fitted to the visible part of its block, so a partly scrolled block keeps a usable handle beside what remains visible; a block wholly outside the view has none.
• Insertion tracking ignores the pointer outside the view, and the button stays inside it, including while its menu is open during scrolling.
• Mod+Alt+I scrolls to the caret first when the caret's block is wholly out of view, so the menu never anchors to a button nobody can see. The specification records this.

Related Issue

Closes #657

Verification

• pnpm exec vitest run src/features/editor/plugins/blockSelectionInteraction.test.ts passed. New cases at both edges of a scrolled view check the layer clip, gutters fitted to the visible part of their blocks, pointer tracking that stops outside the view, and keyboard insertion anchors kept inside it, including an off-view target scrolled in; they fail against the previous plugin.
• pnpm check:frontend passed.
• Added a Windows desktop block-selection scenario that scrolls a nested list item across the top edge and a blockquote across the bottom edge at 640×400, then checks gutter containment, that points just outside the view hit neither a handle nor the insertion button, and that the button hides once the pointer leaves the view. Not run locally; CI runs it.

Manually verified in headless Microsoft Edge on Windows, with the editor mounted in the app's card and ScrollArea at a temporary dev route and driven with CDP mouse input:

1. Before the change, scrolling a block across either edge left gutters outside the view, and a handle and the insertion button received hits outside it.
2. After the change, no gutter crossed either edge, the clipped part of the button received no hit, and moving the pointer outside the view hid the button.

Not verified: larger text sizes and sidebar resizing, beyond the repositioning already triggered by window, document, and view resizes.

Notes

Menus keep their ordinary popup placement; pointer handling through menus is the separate defect the issue names.