[lexical-table] Refactor: use monolithic listener for table SELECTION_CHANGE_COMMAND and deselection handler

[randal-atticus]

Description

As discussed in #8107 the SELECTION_CHANGE_COMMAND and various pointer events are registered for each table in applyTableHandler. There is also a lot of recursive updates going on. It would be better to have a monolithic handler that handles table selection events, as it makes it far easier to reason about what is happening when you have nested tables.

This PR tackles some low hanging fruit:

• SELECTION_CHANGE_COMMAND is hoisted up to registerTableSelectionObserver (i.e. only once). It still runs the old logic ($handleTableSelectionChangeCommand) on each table in sequence though
• pointerDownCallback, which handles clearing table highlight selections, is similarly hoisted up.

Next up is a refactor of $handleTableSelectionChangeCommand so that it just runs once and behaves as expected across all the tables.

Test plan

Before

N/A, this is a refactor

After

N/A no behaviour changes, all tests passing

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
lexical	Ready	Preview, Comment	Mar 4, 2026 6:35am
lexical-playground	Ready	Preview, Comment	Mar 4, 2026 6:35am

[etrepum]

I've only done a quick look at the code here and it seems good, but it might make sense to explicitly add some test coverage to make sure the multi-table (and nested-table?) scenarios work as expected? I don't know what our current coverage of that looks like.

[randal-atticus]

I'll add more multi-table coverage. The nested table scenarios are not well tested, because the current behaviour (when using the mouse) is frankly quite broken, with seemingly nondeterministic outcomes. I tried to add some tests for that in #8107 but I feel like it would now be better to include new nested table tests alongside the a more stable selection handler.