fix(engines): a Simple Packet Block keeps its padding when the interface snaplen is 0 #1558

Describe the bug
When interface 0's snaplen is 0, the default engine includes a Simple Packet Block's padding in the packet data. A snaplen of 0 means no limit.

Reproduction
Use a PCAP-NG with one SHB, one IDB (link type 1) and one SPB, where the SPB's original length is 57 and its data is 57 octets plus 3 octets of padding.

• With IDB snaplen 0, extract(...) gives captured_len/packet of 60 octets.
• With snaplen 65535, it gives 57.
• dpkt, with fix(engines): dpkt float timestamps, Simple Packet Blocks and raw-IP tracing (#1501, #1520, #1548) #1550, gives 57 in both cases.

Expected behavior
57 octets in both cases. The packet is min(original_len, snaplen) octets, with 0 meaning no limit. See the PCAP-NG spec on the Simple Packet Block.

System information
Linux, CPython 3.14.7, main at 16fbea054.

Additional context
pcapkit/protocols/misc/pcapng.py:1201-1206 already skips a zero snaplen (if interfaces and interfaces[0].snaplen:). However, the engine passes 'snaplen': self._get_snaplen() in __packet__ (pcapkit/foundation/engines/pcapng.py:204-209). That passes the 0 straight through, and the setdefault then never applies.

Found by the #1550 review. This is blocked until #1523 merges, because #1523 edits both files.