TCP short writes cause stream corruption

Describe the bug
In TCP mode, link_socket_write_tcp_posix() calls send() exactly once with no retry loop. POSIX does not guarantee that send() on a stream socket writes all requested bytes, i.e. a partial write is a valid outcome. When this occurs, the unwritten tail of the packet is dropped and the TCP framing is permanently broken. Subsequent packets are misframed, decryption fails, and the session restarts.
The caller in forward.c detects the size mismatch and logs a warning, but takes no corrective action (no retry, no connection teardown). The stream is left in a corrupt state.

To Reproduce
We observed the following log sequence on the server side when the peer came under memory pressure:

vpn-seed-server 2026-07-15 20:02:01 vpn-shoot-client-1/tcp6-server:[REDACTED]:45670 Fatal decryption error (process_incoming_link), restarting
vpn-seed-server 2026-07-15 20:02:01 vpn-shoot-client-1/tcp6-server:[REDACTED]:45670 SIGUSR1[soft,decryption-error] received, client-instance restarting
vpn-seed-server 2026-07-15 20:02:01 Closing tun/tap interface

The behavior can also be reproduced deterministically with an LD_PRELOAD shim that intercepts send() and injects a short write. (PR with the reproducer about to follow)

Expected behavior
On a short write, send should be retried for the remaining bytes. The truncation path in forward.c should not leave the stream in an inconsistent state.

Version information

• OS: Alpine Linux
• OpenVPN version: 2.7.3
• Peer OS: Alpine Linux
• Peer OpenVPN version: 2.7.3

Start in src/openvpn/socket.h at link_socket_write_tcp_posix() and trace its caller and size-mismatch handling in forward.c. Use the described LD_PRELOAD send() shim to reproduce a short write. Done means the remaining bytes are handled and the truncation path no longer leaves TCP framing inconsistent.