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/probe-readings.md

@@ -2316,6 +2316,10 @@ run as `--source tcps --source-opt port=44500` against `tools/mock_tcpstreamer.p
 `verification.md`. A service run (`--stream fast` on both sides) reads the same two lines; the mock logs
 `SUBSCRIBE 'fast'`. With no mock the stream line reads `connected=0 signals=0 names= frames=0 ok=0`: a reading,
 not a failure (the retries are quiet on stderr).
+A mock run with `--rate 1000000 --batch 20000` sends frames of about 560 KB; the stream line must still
+read `frames>0 ok=1`. `frames=0` with the mock logging a new client every few hundred ms is the signature
+of a receive buffer smaller than the server's frame (the client drops the connection, reconnects, and
+gets CONFIG again, never DATA).
 
 - `stream: ok=1`: connected, the five names the mock sends (its `time` master channel is a signal of its own, so
   the list is `time,sine,square,ramp,noise`, not four), and frames counted. `connected=0` with a mock running is