Create/check for automated tests for "Warning conflict when editing a page"

This manual test is already covered by automated tests, so no new test is needed.

The scenario (edit conflict on save + the conflict-resolution modal) is exercised by WikiEditIT.editWithConflict() in xwiki-platform-flamingo-skin-test-docker. It reproduces the conflict by editing the same document concurrently in two tabs (functionally equivalent to two browsers/users, since conflict detection is version-based, not user-based) and covers every option from the manual test:

• Step 10 "Merge and fix conflicts with your changes" -> ConflictChoice.MERGE
• Step 12 "Force save your changes" -> ConflictChoice.OVERRIDE
• Step 14 "Reload the editor" -> ConflictChoice.RELOAD
• Steps 16-18 "Fix each conflict individually" -> ConflictChoice.CUSTOM with per-conflict decisions: "your current changes" (DecisionType.CURRENT), "before your changes" (DecisionType.PREVIOUS), "latest version saved" (DecisionType.NEXT), and "custom version" (setCustomValue).

The test goes further than the manual test by asserting the exact merge/force/reload diffs and the saved content after each resolution.

Note on the WYSIWYG editor (non-realtime): the conflict detection and resolution pipeline is shared across editors, not editor-specific. Both the wiki editor and the standalone WYSIWYG editor render the same edit form (previousVersion/editingVersionDate inputs in editactions.vm), submit through the same handler (actionButtons.js, which shows the conflict modal on HTTP 409), and hit the same server-side SaveAction. The WYSIWYG editor plugs into this flow via the CKEditor xwiki-save plugin (xwiki:actions:beforeSave -> editor.updateElement()) rather than implementing its own save/conflict logic. The WYSIWYG-specific merge-and-reload-on-save path is additionally covered by InplaceEditIT.saveWithMergeReloadsEditor().

Proposing to close as already tested.