Handshake packets on the receive path

Law `handshake_receive`: the receive side of the handshake gates the consume functions exactly as
the protocol requires, over ANY sequence of packets of ANY bytes and ANY length.  Code under test besides the
units: receive.c's validate_header_len and wg_receive_handshake_packet, extracted byte for byte
(patch/receive_handshake.c, compiled into this harness only; its calls to send.c / socket.c / timers.c are a
recording shim: DEVIATIONS.md S22, S23).

State: device D with ANY static key, ANY cookie secret and secret age; ANY number of peers (unique public keys)
with ANY handshake state (common.h hs_randomize) and other state (peer_randomize_rest), any reference count below
INT_MAX (common.h draw_peer_refs), entries hashed or not, ANY number of keypairs (whole objects of ANY content,
common.h kents_add; not in the slots, which begin_session rotates) of ANY peers in the table; one peer K whose
private key the harness knows. A sequence of ANY length of packets, with the boot clock moving forward by any
amount, ANY handshake-queue length (the load), ANY rate-limiter answer and ANY source address/port, each packet
one of: ANY bytes of ANY length (other than 148, 92, 64; possibly beginning with K's initiation or response, i.e.
with bytes after a valid message; the type word drawn, or set to 1..4 with or without nonzero reserved bytes; the
last 32 bytes possibly a correct mac1 / mac2 of the rest); 148 bytes with ANY fields or K's initiation to D (the
model's); 92 bytes with ANY fields or K's response to D's current handshake with K (the model's); 64 bytes with
ANY fields (receiver index drawn or one of the table's) or a cookie reply that decrypts for any peer that sent a
mac1; the type word exact, with nonzero reserved bytes, or any; mac1 the correct one (D's mac1 key) or any; mac2
the correct one for D's current cookie of the source, zero or any.  The harness hands a packet to
wg_receive_handshake_packet as wg_packet_receive does: when validate_header_len accepts it and its type word is 1,
2 or 3 (receive.c's UDP/IP parsing and the handshake queue are not covered: DEVIATIONS.md L14).
Claims, for every packet (the model: whitepaper 5.3 / 5.4 and receive.c's load logic):
 - unless the type word is exactly 1, 2 or 3 (reserved bytes zero) and the length exactly 148, 92 or 64
   accordingly, NOTHING changes: every peer as a whole, the device (cookie secret included), the index table;
   nothing is allocated; no call leaves the verified units (a message of type 1 / 2 / 3 with nonzero reserved
   bytes, or of a length that is not exact - also with valid content followed by extra bytes - is dropped);
 - a cookie reply (type 3): exactly law cookie_reply's acceptance and update, nothing else, no call;
 - an initiation or response (type 1 / 2): D is "under load" when the queue holds at least
   MAX_QUEUED_INCOMING_HANDSHAKES / 8 = 512 packets (then last_under_load = now), or else when it last was less
   than 1 s ago, exactly as receive.c decides it: still under load iff NOT (s64)(last_under_load + 1 s) <=
   (s64)now, so exactly 1 s after the last overload D is no longer under load (and last_under_load is reset to
   0) - modelled across the sequence; the verdict on mac1 / mac2 is law cookie_mac's model, with the cookie
   secret replaced by a fresh random one when (s64)(secret birthdate + 120 s) <= (s64)now, i.e. at EXACTLY
   120 s (wireguard-go: only after 120 s); then
     * no valid mac1, or valid macs but rate limited: NOTHING changes but that rotation, no call;
     * under load without a valid mac2: exactly one cookie reply is sent, for the message's sender index, and
       nothing else changes (no consume);
     * otherwise the consume function runs and the result is exactly the model's (laws consume_initiation_any,
       consume_response_any: identity, DH, decryption, known peer, timestamp newer, at least 20 ms since the
       last initiation - accepted at exactly 20 ms -, state CREATED_INITIATION, tag): rejected -> NOTHING
       changes, no call; accepted (peer P) -> P's handshake is the model's (an initiation: CONSUMED_INITIATION
       with the model's hash, chaining key, remote ephemeral, timestamp, indices; a response: the session begins,
       begin_session zeroing it and, unless the allocation fails or P is dead, moving its index to the new current
       keypair), the endpoint is set from THIS packet, a response is sent (initiation) or, if a session was made,
       the session timers run and a keepalive is sent (response), the rx statistics get the packet's length,
       both authenticated-packet timers run - each exactly once, all for P; every other peer unchanged;
       references balanced; nothing allocated but the keypair; no reference count saturates or warns;
 - the packet is never modified.
(After a session is made the harness clears P's keypairs, so that every packet starts from a state of the same
shape; law keypairs covers what sessions do.  The harness draws the boundaries on purpose: queue lengths
510..514, the clock exactly 1 s +- 2 ns after the last overload, 120 s +- 2 ns after the cookie secret's birth,
20 ms +- 2 ns after K's last initiation.)