fix(toolkit): the scapy engine's IPv6 reassembly includes the frame trailer after the IPv6 payload #1584

With engine='scapy', IPv6 reassembly includes the frame's trailing octets after the IPv6 Payload Length in the final fragment's data. A reassembled datagram therefore comes out long and wrong.

Repro on main (e9f3340f7). Take an IPv6 datagram of 80 octets sent as two fragments, 40 + 40 octets. The final fragment's Ethernet frame ends with a 4-octet trailer (deadbeef, like an FCS).

• Default engine: COMPLETE, 80 octets, byte-equal to the original.
• dpkt: the same as the default engine.
• scapy: COMPLETE, 84 octets, not equal to the original.

Expected: the fragment data stops at the IPv6 Payload Length, as on the other engines.

Where: probably ipv6_reassembly in pcapkit/toolkit/scapy.py, which takes the fragment's payload bytes without cutting them at plen.

Found by the #1582 cross-review, then reproduced independently.