docs(core): explain what the parent hop in isWithinEditor is actually for

The previous wording said it covers "UI rendered as a sibling of the
content" without saying which UI that is — and BlockNote's own default
UI is entirely portalled (a mounted editor's container has exactly two
children: the content element and the portal), so on its own that
justification doesn't hold up.

The real case is UI the host app passes as `BlockNoteView` children,
which React renders as siblings of the content element. The shipped
"Static Formatting Toolbar" example is exactly that: `<FormattingToolbar />`
rendered inline rather than through a controller, putting eleven
focusable buttons next to the content. Without the hop, focusing one of
them reads as "outside the editor", which would dismiss the mobile
toolbar mid-interaction and trip the side menu's click-outside check.

Author: YousefED

packages/core/src/editor/BlockNoteEditor.ts

@@ -799,8 +799,15 @@ export class BlockNoteEditor<
    * elements like menus and toolbars).
    *
    * The first check deliberately starts one level up, at the content area's
-   * *parent*, so that UI rendered as a sibling of the content (rather than
-   * portalled) also counts as part of the editor.
+   * *parent*. BlockNote's own default UI is entirely portalled, so that hop
+   * isn't for its sake — it's for UI the host app renders as `BlockNoteView`
+   * children, which React places as siblings of the content element. The
+   * "Static Formatting Toolbar" example does exactly that: it renders
+   * `<FormattingToolbar />` inline instead of through a controller, putting
+   * a dozen focusable buttons next to the content. Without the hop, focusing
+   * one of them would read as "outside the editor" — dismissing the mobile
+   * toolbar mid-interaction, and tripping the side menu's click-outside
+   * check.
    *
    * That makes the result depend on where the editor is mounted, because
    * `editor.mount(element)` turns `element` itself into the content area —