fix: keep the editor gutter inert under open menus

[Azganoth]

Summary

The insertion gutter answered the pointer through open menus in two ways:

• Hover: the insertion button follows the pointer from a document-level mousemove that works from gutter geometry alone, so pointing at a menu item above a gutter showed the button and its line beneath the menu. The heading fold marker's hover is tracked the same way and showed through menus too.
• Press: a modal Base UI menu blocks outside presses with a full-screen backdrop that carries no z-index, while the gutter layer sat at z-20 above it. Clicking the gutter below an open menu closed the menu and, in the same click, opened block insertion; block handles could be pressed the same way.

The gutter layer now stacks at z-0. It is appended to <body> when the editor mounts, so menu portals added later, backdrop included, paint above it and keep the press. Nothing that overlaps the gutter relied on z-20: the titlebar and search panel already stack above it, and the root gutter sits inside the editor's own inline padding.

For hover, utils/editorSurface.ts hit-tests what lies beneath the editor's overlay controls. The insertion button and the fold marker respond only when that element belongs to the editor, which generalizes the fold-marker hit test the gutter already used. Both trackers also listen to mouseover, so a menu opening under a stationary pointer hides the button without waiting for movement.

The specification records that a covering menu or popup keeps the pointer, and the changelog records the fix.

Related Issue

Closes #658

Verification

blockSelectionInteraction.test.ts covers the insertion button hiding while a covering element lies beneath the pointer, including beneath the button itself, and working again once it is gone. headingFold.test.ts covers the fold marker staying hidden under a covering element and returning when the element is removed, with the gutter's own controls skipped. Both tests fail without the plugin changes. pnpm check:frontend passed.

Manually verified in headless Edge 154 on Windows 11 over CDP, with the editor mounted at a temporary Vite route beside a real Base UI menubar menu overlapping the gutter:

1. Before the fix, pointing at a menu item over a gutter showed the insertion button and line, and clicking a gutter below the open menu closed the menu and opened the insertion menu.
2. After the fix, pointing at the menu or its backdrop shows neither, and a heading marker at a covered row stays hidden.
3. Clicking the gutter or a block handle below the open menu only closes the menu: no insertion menu, no block selection, and focus returns to the menu trigger.
4. A menu opened from the keyboard while the pointer rests on the insertion button hides the button, and a click then only closes the menu.
5. After the menu closes, moving over the gutter shows the button again.

A desktop E2E scenario in block-selection.spec.ts hides the sidebar so the File menu overlaps the gutter, then covers hover, a press below the menu, and restored insertion after dismissal.

Not verified: the E2E scenario was not run locally; CI runs it. The Tauri window itself was not exercised.

Notes

• The stacking fix depends on the gutter layer entering <body> before a menu opens. If the editor remounted while a menu was open, its layer would sit above that menu's backdrop until the menu closed; hover would still stay suppressed.
• Heading markers no longer show while the pointer is over the outline panel or the scrollbar at the surface's right edge, since those now count as covering the document.