Fix arrow key navigation in study block table cells

[hendriebeats]

Summary

ProseMirror's default ArrowUp/ArrowDown navigation follows document order, which causes the cursor to jump to the wrong column when navigating the two-column study block table layout. This PR adds a keymap plugin that intercepts arrow keys at cell boundaries and navigates visually instead, using coordsAtPos/posAtCoords to preserve horizontal cursor position.

Details

StudyBlockArrowPlugin.ts

The plugin only activates when the cursor is at the top or bottom edge of a cell (atCellEdge), using a 5px tolerance on the Y coordinate to distinguish single-line vs multi-line cells. When at an edge, it calls findAdjacentCell to locate the target cell in document structure, then resolveLinePos to probe the correct position within that cell at the same X coordinate as the current cursor.

findAdjacentCell handles two distinct row types:

• generalStudyBlock rows (header/body columns) — navigates by row index, preserving which column (header or body) the cursor is in
• questions rows — navigates between questionText/questionAnswer within a question, then across questions, then out to the next generalStudyBlock row

navigateOutOfStudyBlocks handles the case where there's no adjacent cell in the given direction — it exits the studyBlocks node into the preceding sibling (e.g. bibleText) or the next section.

handleSectionHeaderUp covers one additional edge case: pressing ArrowUp from the first line of a sectionHeader when the previous section ends with a studyBlocks node. ProseMirror's default would land at the end of the last cell (right column), but this handler probes the correct column by X coordinate.

Editor.tsx

Registers studyBlockArrowPlugin in the plugin list and fixes the pencil icon src to use window.base for correct path resolution in all deployment contexts.

[boxyoman]

@hendriebeats what does this do?

[hendriebeats]

@hendriebeats what does this do?

@boxyoman I could have done a better job explaining it. On desktop when your cursor is in the study block section and you use the up and down arrow keys to move from block to block, instead of moving to what would seem like the natural position of the cursor above, it will jump to the left or right. This is because the whey prosemirror structures the nodes, by default the cursor can only move to the next node.

This makes it so when you move up and down within the study block sections, the cursor stays horizontally positioned in a way that makes sense

[boxyoman]

@hendriebeats what does this do?

@boxyoman I could have done a better job explaining it. On desktop when your cursor is in the study block section and you use the up and down arrow keys to move from block to block, instead of moving to what would seem like the natural position of the cursor above, it will jump to the left or right. This is because the whey prosemirror structures the nodes, by default the cursor can only move to the next node.

This makes it so when you move up and down within the study block sections, the cursor stays horizontally positioned in a way that makes sense

@hendriebeats I don't have that problem at all when I'm using it.

[hendriebeats]

@hendriebeats I don't have that problem at all when I'm using it.

Yeah it's been so annoying for me ever since we first made it. I wonder if it's a Chrome only thing.

There's two other things to note about the implementation:

1. there were hella edge cases and that's mostly why the change are so long. I wanted it to work in all cases. It's possible it could be done more elegantly, but should work for now.
2. while the code is a bit verbose, it should not negatively impact performance because all the code is gated by computationally inexpensive checks.