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>

ARCHITECTURE.md

@@ -117,9 +117,16 @@ Sent when the signal set changes or a client connects:
 ```
 [uint32 numSigs]
 numSigs × UDPSSignalDescriptor (136 bytes each, packed)
-[uint8 publishMode]   0=Strict/Decimate, 1=Accumulate
+[uint8 publishMode]     0=Strict, 1=Accumulate, 2=Decimate
+[uint64 hrtFrequency]   producer's HRT ticks per second; 0 = unknown
 ```
 
+Everything after the descriptors is an optional trailer: a receiver accepts a
+payload that stops early and ignores bytes it does not know. `hrtFrequency` is
+what lets a receiver on another host turn the raw counter in DATA into seconds
+— without it the only option is the receiver's own timer, which agrees with the
+producer only when the two share a machine.
+
 ### DATA Payload (Strict / Decimate modes)
 
 ```
@@ -130,9 +137,9 @@ per-signal data in CONFIG order (quantised or raw, no inter-signal padding)
 ### DATA Payload (Accumulate mode)
 
 ```
-[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
 ```
 
 ### Quantization / Dequantization