Pinning a capture on a display with 150% scaling produces a pin window
half again as large as the region that was selected. #4614 fixed the
position of that window for v14.0.0; this is the size.

A capture started from the tray icon is fine, because the tray lives in
the daemon and createPin() hands the pixmap straight to attachPin().
Any invocation that runs in its own process instead -- `flameshot gui`
from a shell, a desktop or AutoHotkey shortcut, D-Bus -- finds
FlameshotDaemon::instance() null and serializes the capture to the
daemon. QDataStream writes a QPixmap as a plain image, which carries no
device pixel ratio, so the daemon reconstructs a pixmap that claims a
ratio of 1. PinWidget then lays out device pixels as if they were
logical ones and the window comes out too large by the scale factor.
The built-in PrintScreen hook is not affected; it runs inside the daemon
and takes the in-process path.

Send the ratio next to the pixmap so the serialized path ends up with
the same pixmap the in-process path already gets. Both transports share
the reading half, since the D-Bus adapter and the KDSingleApplication
handler each deserialize the message themselves. A message from an older
flameshot has no ratio appended; the read runs past the end, the stream
reports it, and the pixmap keeps the ratio it already had.

Checked on Windows 11, 1024x768 screen, QT_SCALE_FACTOR=1.5, pinning a
400x300 region. The pin window measured 621x471 before and 422x321
after. The capture is 400x300 device pixels either way, so the pin
should be that plus the 7pt margin on each side, and the patched size
matches the 414x314 measured on an unscaled screen to within the scaled
margin. Unscaled displays measured 414x314 both before and after.