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>

Docs/Protocol.md

@@ -84,8 +84,28 @@ Offset  Size  Type     Field
                                       0xFFFFFFFF = PacketTime (no reference)
 104     32    char[32] unit           null-terminated physical unit string
 ── (total per signal: 136 bytes) ────────────────────────────
+── trailer, immediately after the last descriptor ───────────
+0       1     uint8    publishMode    0 = Strict, 1 = Accumulate, 2 = Decimate
+1       8     uint64   hrtFrequency   producer's HRT ticks per second;
+                                      0 = unknown
 ```
 
+### CONFIG trailer
+
+Everything after the descriptors is a trailer that grew field by field, so a
+receiver must accept a payload that stops early and must ignore bytes it does
+not recognise. An absent `publishMode` means Strict; an absent or zero
+`hrtFrequency` means the producer did not publish its tick rate.
+
+`hrtFrequency` is what makes DATA timestamps interpretable off-box. DATA
+carries the raw value of the producer's high-resolution counter, and on x86
+that counter runs at the TSC frequency — a different number on every model. A
+receiver that divides by its own timer's frequency instead is right only while
+producer and consumer sit on the same host; anywhere else every batch is laid
+out over the wrong span of time. Fall back to the local frequency only when the
+field is missing, and reject implausible values (nothing below 1 kHz is a
+high-resolution timer).
+
 ### Type Codes
 
 | Code | C type | Bytes/element |
@@ -129,7 +149,9 @@ After reassembly, the DATA payload layout is:
 ```
 Offset  Size  Type    Field
 ──────  ────  ──────  ────────────────────────────────────────────────────
-0       8     uint64  hrtTimestamp   hardware reference timer count at Synchronise()
+0       8     uint64  hrtTimestamp   producer's high-resolution counter at
+                                     Synchronise(); divide by the CONFIG
+                                     hrtFrequency to get seconds
 ── for each signal (in config order) ────────────────────────────────────
 varies  N×sz  —       signal data    N = numRows×numCols, sz = element size
                                      (wire size if quantized, raw size otherwise)