Inserting a macro in the realtime WYSIWYG editor scrolls the other users to their caret

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 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.
3. User B inserts a macro (e.g. an Info Box) or changes the parameters of a macro.

Expected: the scroll position of user A doesn't change.
Actual: user A is scrolled to their caret. If the caret of user A is just before the macro (e.g. both users edit the same table cell), it is also moved inside the macro content, so user A ends up looking at, and typing in, the macro inserted by user B.

Analysis

The macro output is not synchronized, so when a remote change inserts a macro or modifies its parameters the realtime editor refreshes the edited content of the other users in order to render the macro (xwiki-refresh command, which overwrites the content with setData). The xwiki-selection CKEditor plugin then restores the selection as it does when users refresh the content themselves (e.g. inserting a macro, switching from Source back to WYSIWYG): it scrolls the restored selection into view, and moves a caret placed just before a macro into the first nested editable of that macro. This is not what the other users expect, since they didn't trigger the refresh and may be reading a different part of the content.

Proposed fix

When the content is refreshed as a result of a remote change, restore the selection without scrolling it into view or moving it, and keep the scroll position the content had before the refresh.