fix: Enter key not creating new line in memo mode on macOS

[devin-ai-integration]

Summary

Adds a direct handleKeyDown prop on the <ProseMirror> component to handle Enter key processing at the view level, bypassing the normal keymap plugin pipeline. This is intended to fix #4964 where Enter fails to create new lines in memo mode on macOS.

The hypothesis is that @handlewithcare/react-prosemirror's event handling pipeline (component event listeners in handleDOMEvents) can interfere with the keymap plugin's handleKeyDown on macOS WKWebView, preventing splitBlock from running for plain paragraph blocks.

The new enterKeyHandler replicates the full Enter key chain (code block exit, newline-in-code, list item split/lift, paragraph split) plus Shift+Enter / Mod+Enter hard break handling, and is exported from keymap.ts and passed as the handleKeyDown direct prop in index.tsx.

Review & Testing Checklist for Human

• Verify the fix actually resolves the bug on macOS: The root cause is hypothesized but not confirmed. Specifically, if the real cause is stale React state in useEditorEventListener closures (slash command / mention handlers returning true from handleDOMEvents.keydown), this fix will NOT help — handleDOMEvents runs before handleKeyDown in ProseMirror's event pipeline, so a stale handler swallowing Enter would still prevent our new handler from firing. Test Enter in a fresh memo with no slash command or mention popup active.
• Test all Enter key behaviors end-to-end on macOS: Plain Enter in paragraphs, Enter in list items (split + lift on empty), Enter in code blocks (newline + exit on empty trailing line), Shift+Enter (hard break), Cmd+Enter (hard break on Mac).
• Verify slash command & mention Enter still work: When the slash command menu or mention popup is active, Enter should select the item, not split the block. This should work because those handlers run in handleDOMEvents which is checked first, but needs manual verification.
• Review the duplicated logic: enterCommand, hardBreakCommand, and exitCodeBlockCommand are near-copies of the logic already in buildKeymap. The view-level handler now runs before the keymap plugin for Enter events, effectively making the keymap's Enter binding dead code. Consider whether maintaining two copies of this logic is acceptable long-term.
• Test on non-macOS platforms: Ensure no regressions on Windows/Linux where Enter presumably works today.

Notes

• The handleKeyDown direct prop has the highest priority in ProseMirror's someProp lookup (checked before view-level plugins and state-level plugins). For Enter keys, the keymap plugin's handler will no longer be reached.
• The duplicated code (~100 lines) could diverge from buildKeymap if either is updated independently. A future refactor could extract shared command definitions.
• Pre-existing typecheck errors (unrelated nodeViews typing) exist on main and are not introduced by this PR.

Link to Devin session: https://app.devin.ai/sessions/03589faf360d4fd69e77bfba0a689014
Requested by: @ComputelessComputer

[devin-ai-integration]

🤖 Devin AI Engineer

I'll be helping with this pull request! Here's what you should know:

✅ I will automatically:

• Address comments on this PR that start with 'DevinAI' or '@devin'.
• Look at CI failures and help fix them

Note: I can only respond to comments from users who have write access to this repository.

⚙️ Control Options:

• Disable automatic comment and CI monitoring

[netlify]

✅ Deploy Preview for hyprnote canceled.

Name	Link
🔨 Latest commit	1022f08
🔍 Latest deploy log	https://app.netlify.com/projects/hyprnote/deploys/69d7bba28c1f4700088d5d4d

[netlify]

✅ Deploy Preview for char-cli-web canceled.

Name	Link
🔨 Latest commit	1022f08
🔍 Latest deploy log	https://app.netlify.com/projects/char-cli-web/deploys/69d7bba243513b000834eccf