fix(reassembly): IPv6 reassembly zero-fills a snaplen-cut non-final fragment and reports it COMPLETE #1567

IPv6 reassembly zero-fills a non-final fragment that the snapshot length cut, and reports the datagram COMPLETE. This was found in the #1564 review and re-measured on both main and e7c9e5fba, which give the same result.

Repro. A 3-fragment IPv6 datagram carries fragments of 64, 64 and 72 octets.

• With the first fragment captured to 60 octets, the result is COMPLETE, 200 octets, with octets 60–63 zero-filled. This holds on the default, dpkt and scapy engines, strict and lax.
• With the first fragment captured to 52 octets, strict gives PARTIAL runs (56, 136) and lax gives a zero-filled payload.

Cause. ipv6_reassembly derives tl from the captured payload (pcapkit/toolkit/pcap.py:244, tl=hdr_len + len(payload)), so a cut can't show up in TL. A non-final fragment must carry a multiple of 8 octets (RFC 8200 §4.5). So an MF=1 fragment whose payload length isn't a multiple of 8 can only be a cut. #1564 applies that rule to IPv4 TSO frames (TL 0).

Expected: PARTIAL, with the missing octets left as a hole, as IPv4 does after #1564.

Blocked until #1564 merges, because the guard lives in pcapkit/foundation/reassembly/ip.py.