clamp packet length in zyfer_receive to bound a_lastcode

[arib06]

clamp recv_length in zyfer_receive before appending to a_lastcode, otherwise a short leading '!' line that seeds a small lencode followed by a packet longer than the buffer's remaining space overruns the 128-byte a_lastcode (recv_length reaches up to RX_BUFF_SIZE), matching the length clamp already used in jupiter_receive.

[hart-NTP]

Thanks for the report, @arib06. Please consider filing a report at https://bugs.ntp.org./ This repo is currently out of date on GitHub, but I checked and this shortcoming persists in the latest code.

[arib06]

Will do, I'll file this at bugs.ntp.org with the details.

For the record, I confirmed it with a standalone ASAN harness that mirrors the else-branch append: seed lencode=1 with a short '!' line, then feed a 220-byte packet. Unpatched that gives a heap-buffer-overflow WRITE of size 220 at the memcpy past the 128-byte a_lastcode; with the clamp it stops at lencode=127 and runs clean. Valid Zyfer input is a 29-byte timecode so it never reaches the clamp.

Happy to leave this PR open or close it once the bug report is in, whichever you prefer.