fix(engines): the scapy engine cuts a captured record at 65,535 octets #1717

Describe the bug
pcapkit's scapy engine hands over at most 65,535 octets of a captured record, even when the file holds more. It reads through scapy's PcapReader.recv, which caps a record at scapy's MTU of 65,535 octets. A longer frame therefore reaches reassembly and the tracer truncated. Under the #1687 best-effort ruling this is still a defect, because the engine loses data it was handed.

Reproduction
#1713 round 3 makes examples/generators/options.py emit a genuine 65,590-octet jumbogram into options-ipv6.pcap (snaplen 262,144). The default engine reads all 65,590 octets. The scapy engine (2.7.0 on 3.14, 2.8.0 on 3.11) delivers frame 13's first 65,535 octets. This was found by the #1713 worker before #1714 deleted the cross-engine test that compared them.

Expected behavior
The scapy engine hands over each record's full captured length. For example, it could read records with a cap of at least the file's snaplen, or pass a larger MTU to the reader. A test should pin the record length on a capture with a record over 65,535 octets.

Blocked until the #1708 scapy revert merges, since both edit pcapkit/foundation/engines/scapy.py.