Problem: multipart send drops unsent frames

[fhgffy]

Fixes #659.

Problem

multipart_t::send() removes a frame before attempting to send it. If the first send returns EAGAIN, the multipart loses that frame and a retry sends an incomplete message. A thrown zmq::error_t also destroys the removed frame. For example, sending first, second, third through an inproc PUSH socket with no peer returns false and leaves only second, third.

Solution

Send the front frame in place and remove it only after the send succeeds. Successfully sent frames are still consumed; the failed frame and remaining suffix stay available. No copying, catch-all handler, or API change is needed.

Add deterministic inproc regression coverage for:

• nonblocking and timed EAGAIN, repeated attempts, both flag overloads, one/three frames, and an empty first frame
• high-water-mark backpressure followed by draining and retry
• EFSM on a REP socket, followed by a valid request/reply exchange and retry
• exact received content/order and an empty multipart after success

Validation

Tested on Linux x86_64, GCC 14.2, libzmq 4.3.5 (DRAFTS enabled, CURVE disabled), Catch2 3.5.3:

• All three new regression cases fail on unmodified master 7f0530688804c2b5b6b0d985773405593fd25ca8 and pass after the fix: 84 assertions
• Related multipart/send_multipart/recv_multipart tests pass: 155 assertions in 7 cases, in C++14 and C++20
• 100 consecutive runs of the new regression cases pass
• A standalone C++11 reproduction fails before and passes after. The CMake configuration requested C++11, but Catch2 raises the unit-test target to C++14; the full suite is therefore reported as C++14
• AddressSanitizer and UndefinedBehaviorSanitizer pass all multipart tests with both the changed header and libzmq instrumented. LeakSanitizer cannot complete in this container; the successful run uses detect_leaks=0
• A separate linker-wrapped C++11 review harness passes simulated first/middle/final send failures, retained suffixes, retry order, empty frames and SNDMORE flags. This checks the wrapper boundary, not real transport failures after partial progress
• Changed lines pass clang-format 20.1.8; git diff --check passes

Full-suite limitations, reproduced on the same unmodified production header: C++14 has 157/177 passing tests after the fix versus 154/177 before; C++20 has 158/180 versus 155/180. The only removed failures are the three new regression cases. The remaining 20/22 tests abort when the container denies libzmq's getifaddrs call with EPERM. Whole-file clang-format also reports existing static_assert formatting from #687 on both base and patched versions; those lines are unchanged. Other compilers, operating systems, libzmq versions, and leak checking remain unverified.