fix(udps): stop packets being dated from an earlier time base

Reported as samples sporadically carrying a previous packet's timestamp:
holes on one side of the stream and collisions on the other, in both the
Go and the MARTe2 receiver. That it appeared in both is what located it
-- the shared cause is upstream of either client. Four independent
defects, all of which end in a packet's values being placed at a time
that is not theirs.

Reassembly slot exhaustion (the "Reassembly slots full; evicting oldest"
flood). Chunk size was learnt only from fragment 0, so an out-of-order
burst destroyed a packet whose bytes had all arrived and left the slot
occupied until the 2 s GC. Slots were keyed on the counter alone, but
DATA and CONFIG number independently, so equal counters merged the two
streams. The 32-byte received-mask covered 256 of the 512 fragments the
client accepts, so a duplicate above 255 was counted as new and the
packet was delivered with a hole of stale bytes in it. And one datagram
was read per Execute(), which cannot drain a fast producer. Fixed with a
pendingTail deferral, (counter, type) keying, a 64-byte mask, a
256-datagram drain, counter-age slot reclamation, and a 1 Hz aggregated
warning in place of the per-eviction flood.

UDPStreamer dropping whole Accumulate batches. EventSem::ResetWait is
Reset-then-Wait, so a Post() landing while the sender thread was inside
ServiceClients()/SendData() was destroyed by the next Reset. The batch
was then skipped with dataReady false, readyFill was never cleared, and
the following flush overwrote it: an entire run of RT cycles never
reached the wire. The record of pending work now lives in the buffers
rather than in the semaphore edge, which also removes up to
UDPS_DATA_WAIT_MS of latency; genuine backpressure overwrites are
counted and reported. Against the unfixed code the new test sees
2999/3000 batches never consumed.

Period inflation after loss. Accumulated scalars carry no SamplingRate,
so the receiver derives dt from the sender-clock gap -- but dividing it
by the previous packet's sample count is only right while nothing is
lost. One loss doubles the reported period, which spreads a batch a full
batch past its own end and into the range the next packet claims. That
is the hole and the collision, exactly. Inferring the cycle count from
the estimate's own period is not a way out: it has a stable fixed point
wherever gap/dt is an integer, so a real rate change locks it at the old
one for good (AccumDtGTest.FollowsSustainedRateChange).

The packet counter removes the ambiguity, so all three receivers now
order on it: a DATA packet that does not advance the counter is dropped
rather than delivered, because its values are older than data already
handed over. Ordering is on the signed difference so it survives the
uint32 wrap, and the sequence resets on reconnect, where the producer's
counter restarts independently of ours. The loss count that falls out of
the same delta feeds the period estimate as cycles = prevN * (1 + lost),
which reduces exactly to gap/prevN when nothing is lost and therefore
still tracks a genuine rate change. UDPSClient::AcceptDataCounter (C++),
udpsprotocol.SequenceGate (Go), decode_data (C).

The C client's existing gap counter was wrap-unsafe and let a stale
packet rewind last_counter, which made every subsequent gap wrong; it
uses the same code now. Docs/Protocol.md gains an Ordering DATA section
stating the requirement for any receiver, including ones outside this
repository.

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

Common/Client/c/udps_client.c

@@ -482,11 +482,36 @@ static int decode_data(udps_client_t *c, const uint8_t *pl, size_t len,
     size_t       total    = 0u;
     size_t       written  = 0u;
     uint32_t     i;
+    uint32_t     lost = 0u;
     udps_frame_t frame;
 
     if (c->num_sigs == 0u) {
         return 0; /* DATA before CONFIG: nothing to decode against. */
     }
+
+    /* Order the sequence before spending anything on the payload.
+     *
+     * Reassembly completes in arrival order, not counter order, so a packet
+     * delayed or duplicated on the wire surfaces after a newer one has already
+     * been delivered.  Its samples carry an older time base: they land on top
+     * of data the consumer already has and leave the span they should have
+     * filled empty.  Nothing in the payload distinguishes such a packet from a
+     * good one, only the counter does.
+     *
+     * The counter is a wrapping uint32, so it is ordered by the signed
+     * difference; comparing the values directly would call the first packet
+     * after the wrap stale and reject the stream from then on. */
+    if (c->have_counter) {
+        int32_t delta = (int32_t)(counter - c->last_counter);
+        if (delta <= 0) {
+            c->stats.stale_packets++;
+            return 0;
+        }
+        lost = (uint32_t)delta - 1u;
+        c->stats.counter_gaps += lost;
+    }
+    c->last_counter = counter;
+    c->have_counter = 1;
     if (len < 8u) {
         return fail(c, "DATA payload too short (%lu bytes)", (unsigned long)len);
     }
@@ -528,15 +553,11 @@ static int decode_data(udps_client_t *c, const uint8_t *pl, size_t len,
         written += count;
     }
 
-    if (c->have_counter && counter > c->last_counter + 1u) {
-        c->stats.counter_gaps += counter - c->last_counter - 1u;
-    }
-    c->last_counter = counter;
-    c->have_counter = 1;
     c->stats.frames_delivered++;
 
     if (c->on_data != NULL) {
         frame.counter      = counter;
+        frame.lost         = lost;
         frame.hrt          = rd_u64(pl);
         frame.recv_time    = recv_time;
         frame.publish_mode = c->publish_mode;

Common/Client/c/udps_client.h

@@ -140,6 +140,16 @@ typedef struct {
 /** One fully decoded DATA packet. */
 typedef struct {
     uint32_t counter;      /**< Packet counter; gaps mean lost datagrams. */
+    /**
+     * DATA packets missing immediately before this one, from the counter.
+     *
+     * Needed to space samples correctly: the elapsed time since the previous
+     * frame covers the lost packets' cycles too, so dividing it by this
+     * frame's sample count alone gives a period too long by exactly
+     * @c lost + 1, which walks the samples past their own end and into the
+     * range the next frame claims.
+     */
+    uint32_t lost;
     uint64_t hrt;          /**< Producer's high-resolution timer at send. */
     double   recv_time;    /**< Wall-clock seconds (CLOCK_REALTIME) at arrival. */
     uint8_t  publish_mode; /**< UDPS_PUBLISH_*. */
@@ -164,6 +174,12 @@ typedef struct {
     uint64_t config_updates;
     uint64_t fragments_dropped; /**< Duplicate, stale or unplaceable fragments. */
     uint64_t counter_gaps;      /**< DATA packets missing from the sequence. */
+    /**
+     * DATA packets dropped for not advancing the counter: reordered or
+     * duplicated on the wire. Delivering one would stamp its values with a
+     * time base older than data already handed over.
+     */
+    uint64_t stale_packets;
     uint64_t reconnects;
 } udps_stats_t;