A Live Data macro is no longer rendered in the in-place WYSIWYG editor after switching to Source and back

This is a regression, introduced in 18.2.0

Bisected over released standalone distributions, testing the same page (a plain
monospace}}liveData{{/monospace macro) with the same automated scenario each time: view the
page, enter the in-place editor, switch to Source and back, and check whether the Live Data is still
rendered.

Version	View	Entering in-place edit	After Source round trip
17.10.13 (LTS)	rendered	rendered	rendered
18.1.0	rendered	rendered	rendered
18.2.0	rendered	rendered	empty
18.8.0-SNAPSHOT (master)	rendered	empty	(the editor never becomes ready)

So 18.1.0 is the last good release and 18.2.0 the first broken one. Note that master fails
earlier and harder than 18.2.0: the Live Data is already destroyed when entering in-place edit
mode, and the JavaScript error that follows also prevents CKEditor from finishing its startup.

Cause

The commit that rewrote the Live Data bootstrap in that range is
monospace}}634b5c5149a{{/monospace - XWIKI-23908 ("Extract Live Data to make it reusable outside
XWiki"), first released in 18.2.0-rc-1. It replaced this (monospace}}services/init.js{{/monospace
in 18.1.0):

const instancesMap = new WeakMap();
const init = function(element, $) {
  if (!instancesMap.has(element)) {
    const logic = new Logic(element, $);
    instancesMap.set(element, logic);
  }
  return instancesMap.get(element);
};

with this:

const data = element.dataset.config
element.removeAttribute("data-config")
...
createApp(XWikiLivedata, {data, ...}).mount(element)

Two properties were lost, and both matter when a Live Data is initialised a second time:

• the new code consumes the configuration - it reads monospace}}data-config{{/monospace and
  removes the attribute - so an already-rendered Live Data no longer carries its own configuration
  (Vue's mount also replaces the children, taking the inline JSON configuration script with them);
• monospace}}createApp(...).mount(element){{/monospace clears the container before rendering,
  whereas the old monospace}}new Logic(element, $){{/monospace did not.

So a second initialisation now wipes the rendered table and then crashes on the configuration that
is no longer there:

Missing live data configuration for element [HTMLDivElement] The HTML content is considered unsafe.
TypeError: Cannot read properties of undefined (reading 'defaultLayout')

leaving the empty monospace<div class="liveData">/monospace this issue is about.

What triggers that second initialisation is the editor: CKEditor re-inserts the edited content as
HTML, so the elements are new DOM nodes and the jQuery monospace.data("liveData")/monospace
marker that guards monospace$.fn.liveData{{/monospace}} does not carry over from the old node.
Worth noting that the same double initialisation already happened in 17.10.13 and 18.1.0 - those
versions log the very same two errors - but the rendered table survived it there, which is why the
guard being ineffective went unnoticed.

Consequence for the fix

Making the guard survive the editor's re-insertion would help, but the initialisation is also no
longer idempotent, which is the part that turns a redundant call into data loss. Restoring one of
the two lost properties - not consuming the configuration, or not clearing the container until the
configuration has been validated - would make a second call harmless again.

Affects Version/s corrected accordingly: 18.2.0 instead of 17.10.13, since 17.10.13 has now been
tested and is not affected.