[lexical-react] Bug Fix: position the typeahead menu relative to its containing block

[LeSingh1]

useMenuAnchorRef absolutely positions the menu anchor and computes its top/left in document coordinates (the caret viewport rect plus window.pageXOffset/pageYOffset). Those coordinates only describe the anchor's position while its containing block is the initial containing block, which is the case for the default document.body parent. When a parent is passed to LexicalTypeaheadMenuPlugin or LexicalNodeMenuPlugin it is normally positioned so that it can contain the menu, and the menu is then displaced by the parent's own offset and scroll position — the misaligned placement described at the end of the report.

The caret viewport rect is now translated into the coordinate space the anchor is actually laid out in. When no ancestor establishes a containing block the previous document-coordinate path is kept unchanged, including shouldIncludePageYOffset__EXPERIMENTAL.

Adds tests in the browser project, since jsdom reports every rect as zero. Without the change the anchor lands 120px right of the caret for a parent with margin-left: 120px, with and without parent scroll; the default-body case is a control that passes either way.

Scoping this as Refs rather than Fixes: the menu selection and scrolling symptoms in the issue title no longer reproduce on main. I checked at 1250x1000, 900x420 and 800x300, and with the editor forced into a short overflow-y: auto container, using both keyboard and mouse — the highlighted item is always the one inserted. The issue was filed against 0.21.0 and main is 0.49.0. This addresses only the mispositioning described in the last paragraph.

Refs #6989

[vercel]

@LeSingh1 is attempting to deploy a commit to the Meta Open Source Team on Vercel.

A member of the Team first needs to authorize it.

[LeSingh1]

Consolidated into #9051 with the other PRs that share this defect, per @etrepum's note on #9027 and @mayrang's on #9035. Same fix and same tests, one review.