fix(dumpkit): a PCAP trace copies a truncated record's claimed incl_len, writing a malformed file #1541

On main f96368b43, a TCP trace (trace_format='pcap') copies a record's claimed captured length verbatim, even when fewer octets are actually present. The trace file it writes is therefore malformed.

Measured on a 4-record PCAP whose last record header claims incl_len 0x7fffffff but has only 585 bytes before EOF. The default engine's trace for that flow writes the record header as incl_len 0x7fffffff, followed by 585 bytes. Any reader then runs off the end of the file. In the same case, dpkt and scapy (with #1511) write 585.

Expected: the trace record's incl_len equals the number of octets written, so a truncated source record yields a well-formed trace. A warning that the source record was truncated would also fit.

The #1511 worker found this (the reviewer's /tmp/r1511/badlen.pcap); I re-derived it on a git archive of main. The fix likely belongs in PCAPIO._append_value (pcapkit/dumpkit/pcap.py) or wherever the frame's frame_info.incl_len is set on a short read.