Mouse stuttering during WiFi network scan on KDE

### Before reporting a bug, please complete the sanity checks above.

- [x] I have done the sanity checks, and my issue persists.

### Deskflow version info

Deskflow: 1.26.0.0 (760e3b99)
Qt: 6.11.1
System: KDE Flatpak runtime
Session: KDE (wayland)

### Build types

Community package (apt, dnf, pacman/aur, brew, etc.)

### Deskflow configuration

- Windows server (1.26.0)
- 1 monitor on windows (left), 1 on linux (right)
- Windows is connected to the access point by cable
- Linux is connected to the access point by WiFi (6)

### What steps will reproduce the problem?

_note: I have had this issue for a long time already, and I recently moved and upgraded to a better WiFi connection, but the setup was similar_

To measure the effect and show the scan:
1. Start `iw event -t` in terminal 1
2. Start `ping -D -i 0.2 192.168.2.1` in terminal 2, where the IP is the access point IP (or router)
3. Open the KDE connection applet while on WiFi or do anything that triggers a scan of WiFi networks

I've used Claude to try and debug this issue and asked it for a summary and added it below the post. I folded it because I personally don't enjoy reading AI written text, but there might be some information that I think is helpful.

### Log output

Show log

_note: DeskFlow logs are not useful here_

The first terminal will show something like:
```
788182954.595901: wlp0s20f3 (phy #0): scan started
1788182959.681313: wlp0s20f3 (phy #0): scan finished: 2412 2417 2422 2427 2432 2437 2442 2447 2452 2457 2462 2467 2472 5180 5200 5220 5240 5260 5280 5300 5320 5500 5520 5540 5560 5580 5600 5620 5640 5660 5680 5700 5745 5765 5785 5805 5825 5845 5865 5955 5975 5995 6015 6035 6055 6075 6095 6115 6135 6155 6175 6195 6215 6235 6255 6275 6295 6315 6335 6355 6375 6395 6415, ""
```

and in the second terminal you will see some random high latency spikes:
```
64 bytes from 192.168.2.1: icmp_seq=30 ttl=64 time=2.35 ms
64 bytes from 192.168.2.1: icmp_seq=31 ttl=64 time=1.89 ms
64 bytes from 192.168.2.1: icmp_seq=32 ttl=64 time=1.23 ms
64 bytes from 192.168.2.1: icmp_seq=33 ttl=64 time=1.71 ms
64 bytes from 192.168.2.1: icmp_seq=34 ttl=64 time=1.22 ms
64 bytes from 192.168.2.1: icmp_seq=35 ttl=64 time=1.32 ms
64 bytes from 192.168.2.1: icmp_seq=36 ttl=64 time=2.03 ms
64 bytes from 192.168.2.1: icmp_seq=37 ttl=64 time=54.6 ms
64 bytes from 192.168.2.1: icmp_seq=38 ttl=64 time=34.2 ms
64 bytes from 192.168.2.1: icmp_seq=39 ttl=64 time=84.5 ms
64 bytes from 192.168.2.1: icmp_seq=40 ttl=64 time=42.5 ms
64 bytes from 192.168.2.1: icmp_seq=41 ttl=64 time=46.6 ms
64 bytes from 192.168.2.1: icmp_seq=42 ttl=64 time=1.35 ms
64 bytes from 192.168.2.1: icmp_seq=43 ttl=64 time=29.2 ms
64 bytes from 192.168.2.1: icmp_seq=44 ttl=64 time=116 ms
64 bytes from 192.168.2.1: icmp_seq=45 ttl=64 time=120 ms
64 bytes from 192.168.2.1: icmp_seq=46 ttl=64 time=0.992 ms
64 bytes from 192.168.2.1: icmp_seq=47 ttl=64 time=1.56 ms
64 bytes from 192.168.2.1: icmp_seq=48 ttl=64 time=1.32 ms
64 bytes from 192.168.2.1: icmp_seq=49 ttl=64 time=1.67 ms
64 bytes from 192.168.2.1: icmp_seq=50 ttl=64 time=1.02 ms
```

Claude Summary

On a Wi-Fi client, brief link latency spikes (measured max 121 ms RTT, **zero
packet loss**) cause the DeskFlow pointer to freeze and then jump. Measured
stalls in event processing reached **800 ms** — noticeably longer than the
underlying network spike — which is why I'm raising it here rather than treating
it purely as a network problem.

The trigger in my case is external to DeskFlow (NetworkManager runs a 4.1 s
63-channel Wi-Fi scan whenever a network UI is opened), but the question for
DeskFlow is whether a ~100 ms hiccup should produce a multi-hundred-ms pointer
stall, or whether queued motion events could be coalesced / stale ones dropped.

## Environment

**Client (where the stutter is seen)**

| | |
|---|---|
| DeskFlow | 1.26.0, Flatpak from Flathub (`org.deskflow.deskflow`), commit `de009819b1d5` |
| Runtime | `org.kde.Platform/x86_64/6.11` |
| Mode | client (`/app/bin/deskflow-core client`) |
| OS | Fedora 44, kernel 7.1.10-200.fc44.x86_64 |
| Desktop | KDE Plasma 6.7.4, **Wayland** |
| Input injection | libei 1.6.0 via XDG RemoteDesktop portal (`xdpRestoreToken` set), xdg-desktop-portal-kde 6.7.4 |
| Wi-Fi | Intel BE200 Wi-Fi 7 (`8086:a840`), iwlwifi, 6 GHz ch 69, 320 MHz, single MLO link |
| NetworkManager | 1.56.1, wpa_supplicant 2.11 |

**Server:** wired to the same AP. *(fill in: OS + DeskFlow version)*

Connection: `192.168.2.16:59514 -> 192.168.2.12:24800` (TCP, on-link, no VPN hop).

## What happens

1. Pointer is driven from the server, moving smoothly.
2. A brief network latency spike occurs on the client's Wi-Fi link.
3. The pointer freezes, then jumps to catch up. Repeats while the spikes continue.

The client's own touchpad stays perfectly smooth throughout, so this is specific
to the network-fed pointer path, not the compositor.

## Measurements

Latency on the client's wireless hop, sampled at 5 Hz with `ping` to the AP
(a probe that runs regardless of whether the mouse is moving):

| Condition | RTT |
|---|---|
| Idle | mean 2.2–2.6 ms, max 4–6 ms |
| During the disruption | mean 9.52 ms, **max 121 ms**, 26/249 packets >20 ms |
| Packet loss | **0%** in every run |

Client-side event processing, sampled at 20 Hz from `/proc//schedstat` and
`/proc/net/tcp` over 35.5 s of disruption while moving the pointer continuously:

- **37 stretches of ≥100 ms with zero voluntary context switches** (i.e. no
pointer events processed), longest **800 ms**, 6.5 s total.
- TCP receive queue stayed **near-empty** during those stalls (max 68 bytes,
versus 4041 bytes seen while idle) — so bytes were not sitting unread in the
socket.
- `deskflow-core` run-queue wait stayed **under 10 ms** throughout, so the
process was not CPU-starved.

**Caveat, stated honestly:** the stall measurement can't fully distinguish "no
events arrived" from "I paused my hand", since DeskFlow only sends on movement.
So treat the 800 ms figure as suggestive, not proven. The RTT numbers are solid.

## Reproduction

Any source of brief link jitter should do. In my case:

```sh
iw event -t # terminal 1 — must be running before the trigger
ping -D -i 0.2 # terminal 2
```

Then open the KDE network applet (or System Settings → Connections). Expect
`scan started` within ~10 ms, `scan finished` ~4 s later, RTT spikes in between,
and visible pointer stutter for the duration.

## Expected / suggestion

A ~100 ms transport hiccup ideally shows up as a single small pointer jump, not
a multi-hundred-ms freeze followed by a replay of intermediate positions. Two
things that might help, if they aren't already done:

- Coalesce queued motion events on receive and apply only the newest position,
rather than replaying the backlog.
- Consider whether anything on the receive path throttles or batches with a
fixed cadence that could amplify a short delay.

## Ruled out on my side (so you don't have to ask)

- CPU contention — `deskflow-core` run-queue wait <10 ms; renicing competing
processes changed nothing
- Wi-Fi power save — disabled at both NetworkManager and driver level
- Signal quality — −51 dBm, 0 tx retries, 0 failures, 0 beacon loss
- VPN — target is on-link, does not traverse the tunnel
- Compositor — local touchpad pointer unaffected at the same moment

### Additional information

_No response_

Start the `/app/bin/deskflow-core client` in client mode and reproduce the issue with `iw event -t`, the AP ping, and the KDE network applet. Trace the network-fed pointer receive path and compare its behavior during the reported latency spikes. Done means a brief roughly 100 ms hiccup no longer causes a multi-hundred-millisecond pointer freeze and replay of intermediate positions.

Written by the indexing model from the issue text.