fix(engines): the pypcapfile engine stops reading at a zero-length PCAP record #1571

With engine='pypcapfile', reading stops silently at the first PCAP record whose captured length is 0, so every later frame is dropped. The default engine reads past such a record.

Repro: a little-endian PCAP with three records of 75, 0 and 77 captured octets.

• On main (a3da376dd), the default engine gives 3 frames and pypcapfile gives 1. I measured this in the Python 3.11 venv with pypcapfile 0.12.0.
• If the zero-length record comes first, pypcapfile gives 0 frames.
• The fix(engines): the pypcapfile engine reads the PCAP records pypcapfile drops (#1512) #1569 review found the same split for a short final record: the default engine yields it and pypcapfile drops it.

Cause: pypcapfile's record reader returns None when not raw_packet_data (pcapfile/savefile.py:221), and its loader treats None as end of file. A caplen of 0 is a legal record.

• The little-endian path inherits this behaviour.
• fix(engines): the pypcapfile engine reads the PCAP records pypcapfile drops (#1512) #1569's _read_big_endian copies it on purpose, so both byte orders behave alike.

Expected: the same frames as the default engine. Keep reading past a zero-length record, and handle a truncated final record as the default engine does.

Found by the #1569 review. It is being fixed in #1569, which already rewrites the record loop in pcapkit/foundation/engines/pypcapfile.py.