fix(toolkit): the pyshark engine traces fragmented TCP at the last fragment, not the first #1612

With engine='pyshark', a TCP segment carried in a fragmented IPv4 datagram is traced at a different frame from the default engine. tshark defragments by default and reports TCP at the frame that completes the datagram. The default engine reads TCP from the first fragment.

Repro on main (c43e9318c), Python 3.11, tshark 4.6.9, on a plain IPv4 capture whose data segments are fragmented. Trace frame indices per flow:

• default: (1, 2) and (6, 7)
• pyshark: (1, 5) and (6, 10)

The #1605 review reports the same for IPv6 first fragments; I have not re-measured that.

Expected: pyshark traces the segment at the first fragment, as the default engine does. One untested option is to run tshark with IP reassembly off: preference ip.defragment:FALSE, and the IPv6 equivalent, via pyshark's override_prefs. #1605's tests exclude first fragments from the pyshark comparison for this reason; that exclusion should go when this is fixed.

Blocked until #1605 merges, because it edits pcapkit/toolkit/pyshark.py.