Bug: [lexical-y] The caret is put back in the wrong place after several unread changes overlapping a local delete are read #9829

@lexical/y: when several remote changes are read together after a local delete that overlaps them, the binding can put the caret back in the wrong place (the content is right).

Example: the line abcdefghijklmnopqrst, caret after n. In one update, A deletes [4,9) and a provider applies B's change (deletes [7,12)) and C's change (deletes [2,5)). After the changes are read, A's text is abmnopqrst (correct), but the caret is at 7 instead of 4 (after n). With gc on, a variant puts it at 2.

The same class as #9825: the binding's view of what it has not read yet classifies whole Yjs items by their first id, and Yjs merges adjacent deleted items again at the end of each transaction. The writes and $resolveCursor now split items at the view's bounds first (#9826); the selection restore inside a read ($restoreSelection / $resolvePosition while other changes are still unread) does not yet. A single remote change maps correctly.