fix: restore Ctrl-click link activation

[Azganoth]

Summary

Ctrl-click (Cmd-click on macOS) on a rendered link, wiki link, or footnote reference did nothing. A real press moves the native caret into the target on mousedown; the editor reads that selection, source projection replaces the rendered target with its Markdown, and no click reaches it. In a table cell, ProseMirror's modifier node selection also outlined the cell's paragraph.

• The link activation, wiki-link navigation, and footnote navigation plugins cancel a primary-modifier mousedown on their own target. The caret stays put, ProseMirror skips its mouseup node selection, and the click activates the target. Plain clicks still place the caret and open the source.
• The Vitest and desktop E2E Ctrl-click helpers now model the press default: unless mousedown is cancelled, the caret moves to the pressed position before mouseup, and no click follows once the pressed element has left the document. The previous helpers dispatched untrusted events, which have no default action, so the fix: suppress modifier-click node selection in ordinary text #655 scenario passed while links stayed broken.

Related Issue

Closes #650

Verification

• pnpm exec vitest run on the link activation, wiki link, footnote navigation, block selection (Windows and simulated macOS), and source projection suites passed. The full-sequence cases cover web and local Markdown targets, mixed-format labels, reference links, links in lists, blockquotes, and table cells, wiki links, footnote references, and Meta-click on macOS; they fail on main and pass with the fix.
• pnpm check:frontend and git diff --check passed.

Manually verified in headless Edge on Windows, with trusted CDP mouse input against the editor mounted at a temporary Vite route and a stubbed Tauri invoke:

1. Ctrl-click on inline, local, mixed-format, reference, quoted, and table-cell links, a wiki link, and a footnote reference reproduced the defect on main and, with the fix, activated each target without projecting its source or selecting a node.
2. Plain clicks on the same targets still placed the caret and opened their source.
3. The desktop helper's page-side sequence reproduced the same failures on main and passed with the fix.

Not verified: the updated block-selection and wiki-links desktop scenarios were not run locally and are left to CI, and the helper's later switch to caretPositionFromPoint is type-checked only. No hardware mouse input in the Tauri app and no native macOS run.

Notes

Footnote-reference Mod+click navigation shared the cause and is fixed here although #650 names only links. Help describes where links open but not the gesture, so it is unchanged.