fix(toolkit): dpkt hands over nothing behind a VLAN tag stack it does not finish decoding in two passes #1654

Describe the bug
With engine='dpkt', an Ethernet frame whose VLAN tag stack dpkt 1.9.8 does not finish decoding in two passes gets no TCP reassembly, trace or IPv4 reassembly input. Examples are three 802.1ad tags, five 802.1Q tags, and 802.1ad followed by four 802.1Q. The default engine and scapy read the IPv4/TCP behind the tags.

Ethernet._unpack_data (dpkt/ethernet.py:90) reads at most two tags per pass. __init__ runs one more pass when the first finds no decoder, and then stops, so dpkt never decodes the payload.

Reproduction on main (b375656e1), Python 3.14.8, dpkt 1.9.8, scapy 2.7.0. Each frame is Ethernet, then the tags (first TPID as the Ethernet type, each tag's next type the following TPID), then IPv4 and a TCP segment with 4 octets of data. Cells are TCP reassembly / trace / IPv4 reassembly inputs:

Three 802.1Q tags raise ProtocolError on main. That is #1646, and its fix leaves these rows as they are.

Expected behavior
dpkt hands over the default engine's inputs for any tag stack the default engine reads. If dpkt cannot decode the payload itself, the toolkit has to walk the remaining tags off the captured octets.