fix: open the context popup from a selection made with the keyboard

[Azganoth]

Summary

A selection made from the keyboard now opens the context popup, as a pointer selection already did. The documents described that behavior for any selection; only the pointer had it.

• Auto-open moves into the plugin's update path, which every selection change already reaches. That covers a selection extended with Shift+Arrow or Mod+Shift+Arrow and one made whole by Select all, without a key binding of its own.
• The request uses the pointer source. A keyboard request moves focus into the popup, which would end the gesture it just opened for; leaving focus in the editor keeps further presses extending the selection, and an open popup stays open rather than reopening.
• Escape latches the dismissal, since it closes the popup without disturbing the selection and the next keystroke would otherwise reopen it. The latch releases when the selection collapses, or when something deliberately opens the popup again.
• A mousedown handler suppresses auto-open for the length of a drag, so the pointer path still opens on release only.
• docs/specification.md gains the open-from-selection and Escape dismissal rules; docs/reference.md names the trigger as a pointer or keyboard selection.

Related Issue

Closes #164

Verification

Added to contextPopup.test.tsx: opening from a selection extended with Shift+Arrow and Mod+Shift+Arrow and from Select all, focus staying on the editor, one popup staying open while the selection grows, the dismissal holding while the selection grows and until it collapses after Select all, and a pointer selection opening only on release.

Manually verified in the desktop app on Windows:

1. Extending a selection with Shift+Right and Mod+Shift+Right opens the popup, which stays open while the caret keeps extending.
2. Mod+A opens it with focus left in the editor.
3. Escape mid-gesture keeps it dismissed while the selection grows, and it opens again once the selection collapses.
4. Shift+F10 and the Menu key still open it with focus, typing still dismisses it, and pointer drag-selection still opens on release.

Notes

• An open popup does not reposition when the selection changes, only when the document scrolls. That predates this change — it follows from how the virtual anchor is registered — and is Context popup keeps its position when the selection it anchors to changes #171, with easing the movement once it exists as Ease the context popup's movement when it repositions #172. The specification wording here avoids claiming otherwise, and the second criterion on Keyboard selection does not open the context popup that the documents promise #164 was narrowed to match.
• The issue offers the end of the selection gesture as a second release for the dismissal, alongside the collapse. It is not implemented: a gesture end is visible only in the keystroke, and a keystroke rule cannot serve Select all, because extending afterwards re-anchors the selection at the text start and would lift the dismissal on the first Shift+Arrow. Collapse-only holds the dismissal longer than the issue requires, and both criteria are "stays dismissed". The cost is that Mod+A straight after an Escape does not reopen the popup until the selection collapses.
• "leaves an unmodified F10 to the rest of the editor" selects text before pressing F10, and that selection now opens the popup on its own. Its mock is cleared after the selection so the assertion still tests only what F10 adds; the assertion is unchanged.