This guard was added as part of d335070b.

The guard as-is does not work correctly. If a client quits at the wrong point
or simply never responds to the request for targets, we get into a stuck state
where we will never update the clipboard from Wayland to X again until the
selection owner changes.

The guard appears to be outdated: The rationale given in the original MR was
that it prevented a race where:
 1. The X11 clipboard changes
 2. We start fetching targets
 3. We notify Wayland clients that the clipboard changed is now empty
 4. Klipper replaces the clipboard
 5. Kwin then replaces the X11 clipboard
 6. X11 finishes fetching targets, but this is now discarded as there's a new
X11 clipboard

However we can not find a path for step 2 to happen in the current codebase.
Potentially due to one of many refactors over the past few years.
The wayland selection is only replaced when targets are fully loaded.

The only wa...