≥1 s delay reopening the main window after it is closed by unfocusing (KDE Plasma?)

**Describe the bug**
In some installs, opening the main window may take an abnormal time in some circumstances. On my KDE Plasma session on Debian 13, the delay is between 1 and 2 s even on a fresh install.

**To Reproduce**
1. Ensure that the “Close When Unfocused“ general preference is enabled.
2. Open the main window
3. Indirectly close the main window, by unfocusing it. Several methods can achieve this, notably:
1. clicking in another application
2. pressing the Windows key (if that is set to open Kickoff or another application launcher).
4. Reopen the main window directly¹

Opening the tray menu does not trigger, and invoking “Show/hide main window” or "Show main window under mouse cursor" via the tray menu does not reproduce.

¹: Direct ways to open the main window are:
1. pressing a global keyboard shortcut for either “Show/hide main window” or "Show main window under mouse cursor"
2. clicking the tray icon
3. `$ copyq show;`

**Expected behavior**
The main window opens instantly.

**Actual behavior**
The main window displays after at least 1 s, but less than 2 s (probably "exactly" 1 s, but this is non-trivial to time, as `$ copyq show;` returns before the window displays).

**Screencast**
https://github.com/user-attachments/assets/257f33e3-3516-42cf-9a86-60934e288a91 depicts a bug similar to this one, but probably not identical. Note that the screencast’s audio is in Opus format, which Firefox does not support. Chromium and VLC do.

**Version, OS and Environment**
CopyQ 16.0.0
Arch: x86_64-little_endian-lp64
Audio: miniaudio 0.11.25
Compiler: GCC
DISPLAY: :0
KGuiAddons: 6.27.0
KNotifications: 6.27.0
KStatusNotifierItem: 6.27.0
OS: Debian GNU/Linux 13 (trixie)
QCA: 2.3.10
Qt: 6.11.1
QtKeychain: 0.15.0
XDG_CURRENT_DESKTOP: KDE
XDG_SESSION_DESKTOP: KDE
XDG_SESSION_TYPE: x11
has-audio: 1
has-encryption: 1
has-global-shortcuts: 1
has-keychain: 1
has-mouse-selection: 1

**Additional context**
When this bug happens, I can reproduce it tens (presumably as many as I wish) of times in a row by simply clicking the tray icon, again, again and again. A direct opening of the main window reproduces if and only² if more than 2 conditions are met:
1. ❓The install is affected.
1. Out of 2 CopyQ installs on Debian 13 I tested, only 1 PC is affected (see above info). Both use KDE Plasma.
2. None of the 3 CopyQ installs on 3 different PCs running Windows I tested reproduces:
1. 1 of 15.0 and 1 of 16.0.0 on Windows 11
2. 1 of 13.0 on Windows 10
3. The main window was indirectly closed (see above) at least once in the current execution of CopyQ.
4. The last time the main window was closed was either via unfocusing or via a primary click on the system tray icon.The set of defects underlying this scenario certainly intersects with the set of those underlying issue #2877.

When this happens, nothing is journaled to CopyQ logs. When a delayed display occurs, the 2 errors mentioned in ticket #3632 are logged to the `systemd` journal. However, these must be red herring, as they are logged whether the display is delayed or not. `systemd` journals nothing more during reproduction.

²: I only experienced this on an install which I mostly “use” to debug CopyQ. The affected PC is the one I use the least, only a few hours per year. I only used that install for a few hours and it will take a while to validate if the above description stands the test of time or if it turns out insufficiently accurate and complete to represent this bug's subtlety.

License
This report (including all messages and attachments I add to it) is offered under the terms of CC0 1.0. This excludes the screencast, which was created by cmvizitiu.