Fix rich-text editor Mod-Enter commit dropping selected content

[cscheid]

What & why

In the format: q2-preview rich-text (tiptap) block editor, committing with Mod-Enter while text was selected deleted the selected text. Most visible path: click a block → select-all → bold → commit → the block was written to disk empty (a tight list item - banana became -; a paragraph was deleted entirely).

Found during end-to-end verification of #376 (rich-text editing for Plain blocks). It is not specific to Plain/list items and not introduced by that change — it reproduces identically on a Para, in the shared, type-agnostic RichTextEditor path.

Root cause

tiptap's HardBreak extension binds Mod-Enter → setHardBreak() — the same key RichTextEditor used to commit, but via a DOM keydown listener that ran after ProseMirror's keymap plugins. So Mod-Enter:

1. fired setHardBreak(), replacing the current selection with a hard break — over a full selection (after select-all + bold) the text is deleted, leaving paragraph[hardBreak];
2. the DOM handler's preventDefault fired too late and committed the emptied doc.

With a collapsed caret it only appended a harmless trailing hard break — which is why plain text edits looked fine but always carried a stray break. The serializer and the Rust commit path were both verified correct in isolation; the fault was entirely in the editor's key handling.

Fix — (A)+(B)

• (B) editorConfig.ts (new): a shared buildRichTextExtensions() disables StarterKit's built-in HardBreak and re-adds one bound to Shift-Enter only, so Mod-Enter never inserts a break. Adds @tiptap/extension-hard-break as a direct dep.
• (A) RichTextEditor.tsx: Escape / Mod-Enter / Enter move into a high-priority tiptap keymap (q2CommitKeymap) that runs inside ProseMirror's keymap and wins deterministically; the racy DOM keydown listener is removed (the focusout-commit is kept). Preserved: Escape cancels, plain Enter is swallowed (no split), Shift-Enter is a hard break, dirty/stale guards.

Rationale for doing both (per maintainer): a hard break on Mod-Enter is never wanted here — the rich editor isn't meant for extensive multi-block editing (the preview's plain-text editor and hub-client's source editor cover that).

Tests

• richtext/editorConfig.test.ts (fast jsdom): a real Mod-Enter over a full selection leaves the text intact; no trailing hardBreak at a collapsed caret; Shift-Enter still inserts one. Verified red with the fix reverted.
• hub-client/e2e/q2-preview-richtext-bold-content-loss.spec.ts (Playwright, real keyboard): bolding a tight-list item and a paragraph now round-trip to **text** on disk with no content loss. Was red before the fix.

Verification

• cargo xtask verify — all steps pass.
• preview-renderer: tsc clean; 487 unit + 517 integration green.
• hub-client: build green; 229 unit tests green; the e2e repro green.

Strand: bd-hafs0qho (discovered-from bd-7pxub583).

🤖 Generated with Claude Code

[posit-snyk-bot]

✅ Snyk checks have passed. No issues have been found so far.

Status	Scan Engine	Critical	High	Medium	Low	Total (0)
✅	Open Source Security	0	0	0	0	0 issues
✅	Licenses	0	0	0	0	0 issues

💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse.