udpsclient: size the TCP receive buffer from max_packet_bytes so large MARTe frames are not dropped

A TCP frame is never fragmented; a real TCPStreamer cycle (240 KB) exceeded the UDP datagram
limit and made the client reconnect forever, seeing CONFIG but never DATA.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

docs/claude/build-and-run.md

@@ -276,8 +276,10 @@ is intentional. Six things were changed:
    `read_tcp_frame()` for the frames, the reorder window forced to 0 (TCP is ordered, so a
    counter gap is a server-side drop and is reported at once), multicast forced off, no
    DISCONNECT frame on close (a write to a closed peer would raise SIGPIPE), no keepalive ACK
-   and no datagram tap. A frame must fit `UDPS_MAX_DATAGRAM_BYTES` (the server's
-   `MaxPayloadSize` default of 60000 does). A stream name over 255 bytes is refused at create.
+   and no datagram tap. The receive buffer is `max_packet_bytes + header` (1 MiB by default,
+   matching the server's frame ceiling) in TCP mode, since a TCP frame is never fragmented and
+   a MARTe cycle of large arrays is one frame; it is `UDPS_MAX_DATAGRAM_BYTES` only for UDP. A
+   stream name over 255 bytes is refused at create.
 
 `deps/plotter` is upstream's own repository and this app's figure support was added
 there rather than worked around here: `Figure::set_min_y_gutter()` (a floor under the