[pa-devbot]

Summary

Follow-up to the TCP security audit of Common/Cpp/Sockets/: a malicious (or merely faulty) peer that accepts a connection but never reads fills the kernel send buffer, and the send() loops on every backend spin on EAGAIN forever, pinning the calling thread. On the Qt backends the undrained write also pins the socket's event thread, which makes close()/connect() on that socket block indefinitely as well.

This PR adds an optional deadline to the client socket:

virtual size_t send(const void* data, size_t bytes,
    std::chrono::milliseconds timeout = std::chrono::milliseconds::max()) = 0;

• Default is ms::max() — the previous unbounded behavior, so existing callers (e.g. SysbotBase::write_data) are unchanged.
• On expiry the loop stops writing and returns the number of bytes actually written, leaving the connection untouched (the caller can retry, close, or keep the connection for reads).
• No backend ever waits longer than before.

Per backend

• POSIX / WinSocket: deadline check at the top of the existing send loop (~5 lines each; Win also keeps the existing partial-write return on expiry).
• Qt (the non-trivial part): the deadline is carried into the queued internal_send call, so the event-thread write loop self-terminates at the deadline — this is what un-pins the event thread so close() (which runs on it) can proceed. The caller-side CV wait becomes timeout + 1 s (queueing margin); the previous flat 5 s safety wait is kept for the infinite default, covering close() destroying the socket before the queued call runs.

Known Qt backend caveat (pre-existing, not changed by this PR)

QTcpSocket::write() accepts the whole payload into Qt's userspace buffer and reports it as written, so kernel backpressure never reaches the write loop on that backend. A stalled peer therefore shows up as "send completed" (data parked in RAM, delivered later if the peer ever reads), not as a partial count. That is also why the new Qt test only asserts timing and close behavior (see below). The bounded-caller guarantee still holds: send() always returns within its deadline.

Test

Test_Sockets_ClientSendTimeout (per backend): loopback pair where the server stalls reading on the first data for 4 s; the client sends 256 MB (far beyond any per-socket kernel autotuning cap) with a 100 ms deadline:

• send() returns in under 1 s;
• POSIX/Win: it returns a partial count (the stalled peer proves the deadline engaged, not a buffer-size coincidence);
• close() finishes promptly and the socket is NOT_RUNNING.

Verification

• pa-build clean; full pa-test command-line suite: 20,327 passed, 0 failed, 3 skipped (including the 2 new tests).
• WinSocket backend compiles via CI (Windows); same 3-line loop change as POSIX.

Notes for reviewers

• Sister PR for the server socket: Sockets: add an optional deadline to ServerSocket::send() #1826 (audit/server-send-timeout). Both add their test near the end of Sockets_Tests.cpp, so the one merged second may need a trivial conflict resolution there.
• Out of scope (separate audit findings, separate PRs): the connect-phase lock held across the connect loop, listener-exception isolation, and the cross-backend send() semantic differences (Win client partial-write return vs POSIX/Qt loop-to-completion; the Qt userspace buffering above).