Clipboard broken on Wayland (Hyprland) controlled side — --server started without WAYLAND_DISPLAY

Bug Description

On a Wayland-only compositor (Hyprland on Arch-based Omarchy), clipboard sync breaks when the machine is the CONTROLLED side: text copied on Windows and pasted into the remote Wayland session does not arrive. The known workaround ("Send clipboard keystrokes") works but is not real clipboard sync.

Root cause: the systemd service (User=root) starts the per-user --server via sudo -E XDG_RUNTIME_DIR=/run/user/1000 -u <user> rustdesk --server but the root service does not carry the user session environment — WAYLAND_DISPLAY is missing from the --server env. The server then picks the wrong clipboard backend (X11 route via Xwayland), which a pure-Wayland compositor like Hyprland does not forward.

Verified fix: give the root service the session env and restart: sudo systemctl set-environment WAYLAND_DISPLAY=wayland-1 DISPLAY=:0
DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus sudo systemctl enable --now rustdesk Then clipboard (both directions), mouse clicks and keyboard all work again. A systemd drop-in makes it persistent across reboots.

How to Reproduce

1. Arch Linux + Hyprland (pure Wayland), RustDesk 1.4.9 running as the standard root systemd service (rustdesk.service)
2. Connect from Windows 11 (RustDesk client) to the Wayland machine
3. Copy text on Windows, try to paste in the remote Wayland session
4. Observe: nothing arrives
5. Check the --server process env: WAYLAND_DISPLAY is absent (tr '\0' '\n' < /proc/$(pgrep -f 'rustdesk --server$' | head -1)/environ)
6. After systemctl set-environment WAYLAND_DISPLAY=... DISPLAY=:0 DBUS_SESSION_BUS_ADDRESS=... + service restart: paste works

Expected Behavior

Clipboard sync from the controlling side into a Wayland-only controlled side should work out of the box (same as it does when DISPLAY/WAYLAND env reaches the --server, e.g. on GNOME/Ubuntu).

Operating system(s) on local (controlling) side and remote (controlled) side

Windows 11 -> Arch Linux (Hyprland, Wayland)

RustDesk Version(s) on local (controlling) side and remote (controlled) side

1.4.9 -> 1.4.9

Screenshots

N/A

Additional Context

Related: #3455 (Shared Clipboard not Functioning with Wayland), #13338 (Wayland->Wayland clipboard paste fails), PR #5900.

Why not a user service: running rustdesk --server directly as a user service inherits the session env, but then mouse CLICKS and KEYBOARD input stop working — the virtual uinput device is managed by the --service (root) process; root is required for /dev/uinput. Only the drawn cursor moves.

Suggested code fix: in src/platform/linux.rs try_start_server_, always inject WAYLAND_DISPLAY and DBUS_SESSION_BUS_ADDRESS from the detected desktop session into the --server env, matching what the xdg-desktop-portal processes expose.