fix(udps): publish the producer's HRT frequency so timestamps survive the hop

DATA packets timestamp with the raw value of the producer's high-resolution
counter, and the wire never said how fast that counter runs. The hub divided by
its own timer's frequency instead, which is only the same number while producer
and hub share a machine — on x86 it is the TSC frequency and differs from model
to model. Off-box, every accumulated batch was therefore laid out over the wrong
span of time: the samples in it drift away from where they belong and start
colliding with the next packet's, which is the "same" symptom as a stale time
base even though nothing is out of order.

CONFIG now carries the rate as a trailing uint64, alongside the publish-mode
byte and read the same tolerant way: absent or zero means the producer did not
say, and the hub falls back to its own timer as before. Anything below 1 kHz is
not a high-resolution timer and is refused, so a mis-parsed payload cannot
stretch a millisecond batch across seconds.

The Accumulate DATA payload is unchanged, so this costs nothing per packet and
the period *within* a batch is still estimated from the gap between packets.

The Go, C and browser parsers already ignore trailer bytes they do not know,
so they read the new CONFIG unchanged; none of them uses the HRT timestamp.

Also corrects the Accumulate DATA layout in all three protocol documents: they
described it as one snapshot per array signal, where it has always been one per
accumulated cycle.

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

Common/UDP/UDPSProtocol.h

@@ -22,16 +22,23 @@
  * CONFIG payload:
  *   [uint32 numSigs]
  *   numSigs × UDPSSignalDescriptor (136 bytes each, packed)
- *   [uint8 publishMode]   (PublishModeStrict / Accumulate / Decimate)
+ *   [uint8 publishMode]     (PublishModeStrict / Accumulate / Decimate)
+ *   [uint64 hrtFrequency]   ticks per second of the producer's HRT
+ *
+ * Everything after the descriptors is an optional trailer: a receiver must
+ * accept a payload that stops early and must ignore bytes it does not know.
+ * publishMode defaults to Strict when absent, hrtFrequency to
+ * UDPS_HRT_FREQUENCY_UNKNOWN.
  *
  * DATA payload (Strict / Decimate):
  *   [uint64 HRT timestamp]
  *   per-signal data in CONFIG order (quantised or raw, no padding)
  *
  * DATA payload (Accumulate):
- *   [uint64 HRT timestamp]
- *   [uint32 numSamples]
- *   for each signal: if scalar → numSamples elements; else → NumElements once
+ *   [uint64 HRT timestamp of the first slot in the batch]
+ *   [uint32 numSamples]     RT cycles accumulated into this packet
+ *   for each signal, in CONFIG order: numSamples × NumElements values
+ *   (signal-major, one full snapshot per accumulated cycle)
  */
 
 #ifndef UDPS_PROTOCOL_H_
@@ -123,6 +130,20 @@ static const uint8 UDPS_PUBLISH_STRICT     = 0u; ///< One packet per Synchronise
 static const uint8 UDPS_PUBLISH_ACCUMULATE = 1u; ///< Variable batch; flush on size or time
 static const uint8 UDPS_PUBLISH_DECIMATE   = 2u; ///< One packet per Ratio calls
 
+/*---------------------------------------------------------------------------*/
+/*                   HRT frequency (CONFIG trailing uint64)                  */
+/*---------------------------------------------------------------------------*/
+
+/**
+ * Sentinel for a CONFIG that carries no HRT frequency, either because the
+ * trailer is absent (producer older than this field) or because the producer
+ * could not determine it.  DATA timestamps are raw ticks of the producer's
+ * high-resolution timer, so without this a receiver on another host has no
+ * way to turn them into seconds and can only fall back to its own timer's
+ * frequency — which is right only while the two happen to agree.
+ */
+static const uint64 UDPS_HRT_FREQUENCY_UNKNOWN = 0u;
+
 /*---------------------------------------------------------------------------*/
 /*                   CONFIG payload — per-signal descriptor                  */
 /*---------------------------------------------------------------------------*/