Performance updates

[zoltanhosszu]

Performance and Memory Management Improvements for Lexxy

This PR addresses performance bottlenecks and memory leaks identified in Lexxy, particularly noticeable when editing large documents.

Key Changes

DOM Query Caching in Toolbar

• Cache button and menu element references on initialization instead of querying the DOM on every update
• Removes ~15 querySelector calls per keystroke

Table State Consolidation

• Consolidate scattered table state reads into a single cached tableState getter
• Previously, each table operation triggered separate editor state reads; now they share one cached result per update cycle

Memory Leak Fixes

• Add destroy() method to CommandDispatcher with proper cleanup of drag/drop handlers and command registrations
• Store and call unregister functions for all registerUpdateListener and registerCommand calls
• Fix event listener cleanup in toolbar, code language picker, and table tools

Update Listener Optimization

• Skip update listener callbacks when dirtyElements and dirtyLeaves are both empty (no actual content changes)
• Reduces unnecessary work during selection-only changes

[samuelpecher]

A great step in the right direction. I particularly like the tableState extraction if we avoid any issues around batched updates potentially calling stale state.

[samuelpecher]

I'm onboard with the idea here, especially removing the frame await, but this can't be a large part of the performance win since it's only on programmatic set value ?

Do we have a test that fails without the previous code, and then passes with { discrete: true } to be sure this handles the problem?

I'd also port the comment to explain the use of discrete

[zoltanhosszu]

I'll be honest, this was a suggestion from Claude, after analyzing Lexical+Lexxy code. Tests pass in all 3 variants, so we might not have a proper test for this?