fix(toolkit): dpkt reads TCP and IPv6 fragments past the end of an IPv6 packet whose Payload Length is zero #1651

Describe the bug
With engine='dpkt', an IPv6 packet whose Payload Length is 0 does not get the default engine's TCP reassembly, trace or IPv6 reassembly inputs:

• No Jumbo Payload option. The default engine dissects no payload, so it finds no TCP and no Fragment header. dpkt hands one over anyway, with its payload running to the end of the record, link-layer trailer included.
• With a Jumbo Payload option (RFC 2675). The default engine's payload ends at the Jumbo Payload Length (pcapkit/protocols/internet/ipv6.py:224). dpkt's keeps going: into a trailer, or, with no trailer, past a Jumbo Payload Length shorter than the packet.

6in4 behaves the same way, except that the IPv4 Total Length already cuts off a trailer.

dpkt 1.9.8 cuts an IPv6 payload only when the Payload Length is non-zero (dpkt/ip6.py:76). tcp_reassembly (pcapkit/toolkit/dpkt.py:975) and tcp_traceflow (:1039) take tcp.data as it is (:1029, :1095). ipv6_reassembly (:866) also cuts at the Payload Length only when it is non-zero (:909).

Reproduction on main (b375656e1), Python 3.14.8 and 3.11.15, dpkt 1.9.8.

Each case is an Ethernet frame, carrying 6in4 where the row says so. The IPv6 packet has the Payload Length shown and carries either a TCP segment with 4 octets of data, or one IPv6 Fragment header (offset 0, M=1, 16 octets of data). The trailer is 6 octets of 0xee. Extracted with reassembly=True, tcp=True, ipv6=True, trace=True.

TCP cells give the reassembly payload octets / whether it was traced (- means none). Fragment cells give the payload octets of the IPv6 reassembly input.

pypcapfile declines TCP over IPv6 by design (pcapkit/toolkit/pypcapfile.py:23), and pyshark does no reassembly, so neither is shown.

Expected behavior
dpkt hands over the same inputs as the default engine. For a Payload Length of 0 with no Jumbo Payload option, that means no input. Otherwise, the payload ends at the Jumbo Payload Length.