fix(client): apply the server clipboard size limit to the receive path

Client::setOptions stored kOptionClipboardSharingSize in
m_maximumClipboardSize, the send cap, but never applied it to
m_maximumClipboardReceiveSize. That member was written only once, in the
constructor, from this machine own server/clipboardSize setting, so the
value the server advertised was received and then ignored for receiving.

A server configured with a larger limit than the client therefore had its
clipboard transfers rejected by the client with "clipboard size exceeds
limit", while client -> server transfers of the same payload succeeded. The
failure appeared in one direction only, and the limit being enforced was not
reachable from the client GUI at all: the only control lives in the server
config dialog, which is hidden when running as a client.

The option is in KiB and the member is in bytes.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

src/lib/client/Client.cpp

@@ -344,6 +344,16 @@ void Client::setOptions(const OptionsList &options)
       index++;
       if (index != options.end()) {
         m_maximumClipboardSize = *index;
+        // the server is authoritative for the shared clipboard limit, so apply it
+        // to the receive path as well.  without this, the receive cap keeps the
+        // value computed from this machine's own setting in the constructor, and a
+        // server configured with a larger limit has its transfers rejected here
+        // with "clipboard size exceeds limit" -- a failure that shows up only in
+        // the server -> client direction, since the send cap above is already
+        // driven by this option.
+        //
+        // the option is in KiB; m_maximumClipboardReceiveSize is in bytes.
+        m_maximumClipboardReceiveSize = static_cast<size_t>(*index) * 1024;
       }
     } else if (id == kOptionRelativeMouseMoves) {
       index++;