fix: a full reorder ring keeps the arriving packet and counts the overflow, instead of dropping it silently

A packet that needed a slot and found none was neither held nor delivered: no
counter recorded it and the consumer reserved a hole nothing could ever backfill.
It now commits the gap to free a slot and takes the ordering decision once more
against the sequence that commit left behind, bounded to one retry; past that it
is delivered in order with the counters it skipped as its `lost`, never flagged
late, because a packet ahead of the sequence has no hole to be looked up by. A
duplicate can now replace its slot at a full ring, as hold_packet's own comment
already promised, and the 20 ms default window is a named constant.

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

deps/udpsclient/udps_client.h

@@ -202,6 +202,15 @@ typedef struct {
      * before the window existed they were counted in @c stale_packets and dropped.
      */
     uint64_t late_delivered;
+    /**
+     * Times a DATA packet needed a slot in the reorder ring and found none, so the
+     * current gap was committed early to make room. Every such packet is still held
+     * or delivered -- none is dropped -- but the window it was given was shorter
+     * than @c reorder_window_s asked for. A non-zero reading says the ring is
+     * undersized for the stream's reordering depth, which is a reading and not a
+     * mystery; it is the only place that shows up.
+     */
+    uint64_t reorder_overflows;
     uint64_t reconnects;
 } udps_stats_t;