Fix: cap context menu height so it doesn't render off-screen

[julcap]

Summary

The per-node context menu (Type / Insert / Duplicate / Remove) and the append-node menu are constructed without limitHeight:

const menu = new ContextMenu(items, { close: onClose })

TreePath.js's breadcrumb menu already opts into this:

const menu = new ContextMenu(items, { limitHeight: true })

Without it, ContextMenu.show() can fall back to "show below" even when neither direction has enough room, and the menu's own height is never capped. In an editor embedded in a size-constrained container (e.g. a small panel, an iframe, a modal), this means the bottom items of the menu (typically Duplicate/Remove) render past the container's edge and become unreachable - there's no scrollbar, they're just cut off.

This is the same underlying gap described in #571 for the general "popups can't overflow the editor" case, specifically for the per-node context menu, which never got the limitHeight treatment TreePath.js already has.

Change

Pass limitHeight: true in both places ContextMenu is constructed for per-node menus (src/js/Node.js, src/js/appendNodeFactory.js), mirroring the existing TreePath.js usage. This caps the menu's list height to the actually-available space and adds an internal scrollbar (both handled already inside ContextMenu.show() when limitHeight is set), so the menu always renders fully inside the frame instead of being clipped.

Testing

• npm run lint passes.
• Manually verified against the ContextMenu.show() collision-detection logic, which already implements the height-limiting behavior for TreePath.js's menu - this change only extends the same, already-proven option to the two other call sites.

Related to #571.