[lexical-table] Bug Fix: Shift+Arrow no longer throws when the anchor is off the rect corner

[LeSingh1]

Description

$adjustFocusInDirection needs to know which corner of the selection rect the
anchor sits on, so it can move the opposite corner:

const rect = $computeTableCellRectBoundary(tableMap, anchorCellValue, focusCellValue);
...
const anchorCorner = getCornerOrThrow(rect, anchorCellValue);

$computeTableCellRectBoundary does not return the rect through the two cells
— it grows that rect until it contains every merged cell that straddles an
edge, so a merged cell can push an edge out past the anchor. When it does,
getCorner returns null for the third case in its {minColumn, maxColumn,
neither} test and getCornerOrThrow fires its invariant, killing the editor
update mid-keystroke. The anchor and focus of a TableSelection are never
normalised to rect corners — $setAnchorCellForSelection and
$createTableSelectionFrom just record the two cell keys — so nothing upstream
prevents it.

Repro: in a 3x3 table merge grid columns 0–1 of row 1, drag-select from
(row 0, column 1) to (row 1, column 2) — the highlight correctly shows the
expanded block — then press Shift+ArrowDown.

$extractRectCorners, 24 lines below, asks the identical question about the
same expanded rect and handles the null case: it falls back to the corner
opposite the focus, then to the top-left. This gives $adjustFocusInDirection
the same three-tier resolution via a shared getAnchorCorner helper.
getCornerOrThrow had no other call site and is removed with it.

Test plan

npx vitest run packages/lexical-table/src/__tests__/unit/ShiftArrowOffCornerAnchor.test.ts

(The natural test file, LexicalTableSelectionHelpers.test.ts, is already
being edited by an open PR, so the repro lives in its own file.)

Before

 FAIL  ... > Shift+Arrow with an anchor that is not on a rect corner > extends the selection instead of throwing
AssertionError: expected [Function] to not throw an error but 'Error: getCornerOrThrow: cell 7 is no…' was thrown

- Expected:
undefined

+ Received:
"Error: getCornerOrThrow: cell 7 is not at a corner of rect"

After

 Test Files  1 passed (1)
      Tests  1 passed (1)

Also green:

• npx vitest run packages/lexical-table — 13 files, 158 tests
• E2E_BROWSER=chromium npx playwright test --project=chromium Tables.spec.mjs — 88 passed, 1 skipped
  (this suite includes the shift-selection groups that exercise $adjustFocusInDirection)

Only chromium was exercised locally for the e2e run.

[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.

[mayrang]

Confirmed the bug on main (throws getCornerOrThrow: cell 7 is not at a corner of rect) and all 158 tests pass on this branch. The three-tier fallback in getAnchorCorner mirrors $extractRectCorners correctly. A few test coverage notes inline — the main one is that KEY_ARROW_DOWN_COMMAND is the only direction exercised, while each of the four directions takes a distinct branch through $adjustFocusInDirection.

[mayrang]

Two coverage gaps here:

1. isValid() passes for any coherent TableSelection, so a future change to the fallback branch would go undetected. The opposite-of-focus path produces deterministic cells worth pinning:

const [map] = $computeTableMapSkipCellCheck($table(), null, null);
expect(selection.anchor.key).toBe(map[0][0].cell.getKey()); // top-left (oppositeCorner of focus's maxColumn/maxRow)
expect(selection.focus.key).toBe(map[2][2].cell.getKey());  // bottom-right after one row down

(Verified — these are the actual post-keystroke values.)

2. Only KEY_ARROW_DOWN_COMMAND is exercised. Each of the four arrow directions takes a distinct branch in $adjustFocusInDirection — Up, Left, and Right should also be covered.

[mayrang]

When both anchor and focus are off-corner, getAnchorCorner returns ['minColumn', 'minRow'], making $adjustFocusInDirection treat maxColumn/maxRow as the focus side. For direction === 'up' and direction === 'backward' this means focus moves inward rather than outward. $extractRectCorners carries a TODO acknowledging the same arbitrariness ("use the closest corner instead") — worth mirroring that note here so the limitation is visible at this call site too.

[mayrang]

LexicalTableSelectionHelpers.test.ts (the sibling file in this package) declares the editor as let editor: LexicalEditorWithDispose — the named export from @lexical/extension. ReturnType<typeof buildEditorFromExtensions> is equivalent but inconsistent with the local pattern.

[LeSingh1]

Consolidated into #9054 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.