protocol: Bound the job-validation parser and guard clz(0)

[jasonsopko]

What

Two out-of-bounds reads in the DATUM protocol parser, both reachable from the pool the gateway connects to. Same code as CONVOY, where these went up as separate PRs.

• datum_protocol_job_validation_cmd() read the subcommand byte before its len < 2 check and passed no length to the stxlist, stxlist-by-id and sblock handlers. _stxlist_byid() then read a three-byte header and two bytes per requested id, the id count bounded only against the template's transaction count, never against the received length. A short or crafted request reads past the frame, and with a valid job the surplus is copied into the reply and sent back to the pool.
• roundDownToPowerOfTwo_64(0) evaluated 1ULL << (63 - __builtin_clzll(0)); __builtin_clzll(0) is undefined. floorPoT() next to it already guarded its zero case. Reached through a server minimum-difficulty of 0 and through the vardiff path.

Why

datum_protocol_mining_cmd5() dispatches with cmd_len taken from the server's header, and the receive loop delivers exactly that many bytes, which can be as few as one, so the handlers read frames shorter than they assume. server_recv_buffer is a large static array, so on x86 these are reads of stale bytes rather than faults, but they are out-of-bounds reads of attacker-influenced length in a network parser.

How I tested

Found by a libFuzzer harness over datum_protocol_mining_cmd5 on the CONVOY tree; the same functions are byte-identical here. Built this fork with gcc -Wall -Werror, datum_gateway --test passes, and the three reproducing inputs replay clean under AddressSanitizer and UndefinedBehaviorSanitizer with the fixes. Each guard is a return 0 on a frame too short for what the code then reads, a no-op on well-formed traffic.

Risk and rollback

Valid pool traffic takes the same path. Revert either commit independently.