Remote changes keep scrolling the realtime WYSIWYG editor to the caret once the edited content has been refreshed

Analysis, text and proposed fix by Claude Code with Opus 5.5

Steps to reproduce

1. Two users edit the same page in realtime with the WYSIWYG editor (standalone or in-place). The page is long enough to be scrolled.
2. User B inserts a macro, e.g. an Info Box. This refreshes the edited content of all users, in order to render the macro. User A inserting a macro, or switching to Source and back, has the same effect.
3. User A places the caret somewhere in the content, then scrolls to another part of the content using the mouse wheel or the scroll bar, without clicking in the content.
4. User B types in the paragraph of user A, before the caret of user A.

Expected: the scroll position of user A doesn't change.
Actual: user A is scrolled back to their caret. If the caret of user A is just before a macro that has content editable in-place, it is also moved inside that macro.

This happens for every later remote change that prevents the editor from keeping the caret of user A precisely (see below), not only for the first one, until user A reloads the editor. When the restored caret isn't exactly where it was (see XWIKI-25613), user A is scrolled to a seemingly random place.

Analysis

The xwiki-selection CKEditor plugin scrolls the restored selection into view only if the edited content was overwritten (setData) after the selection was saved, which is what happens when the content is refreshed to render macros or when switching from Source back to WYSIWYG. It records this with a contentOverwritten flag on the saved text selection, set by its setData listener. The text selection object is reused each time the selection is saved, and nothing clears the flag. So after the first content overwrite, every later restore of the text-based selection scrolls the selection into view, and moves a caret placed just before a macro into the first nested editable of that macro.

The realtime WYSIWYG editor restores the text-based selection whenever a remote change prevents it from keeping the selection precisely, e.g. when text is inserted before the caret in the same text node, or when the remote patch rewrites the paragraph holding the caret (see XWIKI-25613).

Proposed fix

Clear the flag each time the selection is saved, so that it means "the content was overwritten since the selection was saved".