fix: reach and operate the editor context popup by keyboard

[Azganoth]

Summary

The context popup opened from Shift+F10 and the Menu key but focus stayed in the editor, Tab closed it and sent focus somewhere unrelated, and any arrow key collapsed the selection and closed it. It was also exposed as an unnamed role="dialog" whose fourteen controls would each have become a tab stop once focus could reach them.

• A keyboard open takes focus. Shift+F10 and the Menu key are handled as editor keys rather than through the contextmenu event they produce, which also suppresses that event so the pointer path cannot reopen the popup underneath the keyboard one. Requests carry the source they came from, and an open popup keeps it, so refreshing its anchor against a moved selection cannot downgrade a keyboard open to one that never took focus.
• A pointer open does not. Right-click and mouse-selection opens leave focus in the editor, unchanged.
• The popup is a labeled toolbar. role="toolbar" with an accessible name, and Radix's toolbar carries the roving tabindex and horizontal traversal, so the controls are one tab stop rather than fourteen. The unnamed role="group" rows are gone.
• Two keys the toolbar cannot leave to Radix. Vertical arrows move between the wrapped rows at the nearest available column, skipping a row with nothing available, because roving focus only walks controls in document order. Escape closes from inside, because the focused control's tooltip is the dismissable layer Radix offers Escape to first.
• Closing returns focus to the editor with its selection intact, on every path that was holding focus.
• A scroll no longer closes the popup while focus is inside it, and still does while focus is in the editor.

src/components/ui/Toolbar.tsx is new: a data-slot wrapper over @radix-ui/react-toolbar, which the installed radix-ui package already provides. shadcn/ui ships no toolbar to base it on, and ToggleGroup is the wrong semantics for command buttons.

Related Issue

Closes #120

Verification

Automated (pnpm check:frontend, Windows 11, 951 tests across 92 files, exit 0):

• EditorContextPopup.test.tsx covers the toolbar role and name, the absence of a dialog and of unnamed groups, all fourteen controls outside the tab sequence, arrow traversal on both axes with column clamping and a skipped unavailable row, wrapping, Enter on a command and through a submenu, Escape, Tab, focus entry per open source, focus return, and both scroll cases.
• contextPopup.test.tsx covers both context-menu keys, an unmodified F10 left to the editor, the caret and selection anchors, the source surviving an anchor refresh, and the editor selection surviving focus leaving and returning.
• The submenu Escape and outside-click tests were confirmed to fail against the unmodified component by stashing only EditorContextPopup.tsx. Both assert against a parent that really closes; a mock onClose leaves the popup mounted and makes any "still open" assertion pass regardless.
• Coverage thresholds clear without change: statements 90.38%, branches 81.15%, functions 91.83%, lines 91.89%.

Manual, on Windows 11 through pnpm tauri dev:

1. Shift+F10 and the Menu key open the popup and move focus into it, in a paragraph, a list, and a table alike.
2. Right-click and mouse selection open it without moving focus.
3. Every quick action, inline format, block format, and both submenus operate from the keyboard; arrows move between controls instead of collapsing the selection.
4. Closing returns focus to the editor with the selection intact, and the commands act on that selection.

Not verified: Escape inside an open submenu and clicking outside while the popup holds focus, both covered by tests only; platforms other than Windows; a bundled build.

Notes

• The issue expected removing the onCloseAutoFocus prevention to be enough, since with only a PopoverAnchor Radix's restore is a no-op. The no-op holds, but PopoverContentNonModal calls event.preventDefault() immediately after it, which suppresses the focus scope's own restore, so removing the prevention drops focus to <body>. The popup returns focus itself instead, and only when it was holding it.
• The issue also expected the two open paths to be told apart inside the contextmenu handler. That requires reading a synthesized MouseEvent, which reports no button for a keyboard invocation; handling the keys directly needs no such inference.
• ArrowDown on a submenu trigger opens the submenu rather than leaving the row, which is what a menu button should do. The consequence is that downward wrapping from the last row is unreachable, since both bottom rows are submenu triggers; upward wrapping works.
• Escape is layered, closing an open submenu before the popup, matching the menu bar. The tooltip a focused control shows is the exception, skipped because it is a consequence of focus rather than something the user opened.
• Tab and Shift+Tab close the popup and return focus to the editor rather than cycling inside it. The toolbar is one tab stop by construction and the arrows already wrap, so cycling would trap focus to no end.
• Out of scope and unchanged: the command menu bar (Menu bar recent items are ungrouped and fully disabled submenus open empty #119), which commands appear in the popup and their availability rules, and the popup's mouse behavior.