fix(protocols): an IPv6 extension header behind a Fragment header stops TCP dissection #1539

Whether the default engine dissects TCP after an IPv6 extension header depends on whether a Fragment header comes first. Measured on main 81efa6035, one Ethernet frame each:

The #1535 review found the same split for a zero-filled HIP header and a Routing header of type 3 (RPL). Both reach TCP directly, but not behind a Fragment header. HbH, DstOpts, AH, MH and well-formed Routing headers reach TCP either way.

Likely cause (not traced in a debugger):

• IPv6 stops its own extension-header walk at a Fragment header (pcapkit/protocols/internet/ipv6.py:584, then break).
• Mid-walk, a header whose parser raises is replaced by IPv6_Ext. But the dispatch after the break goes through Internet._decode_next_layer without extension=True, so a failing header degrades to a leaf instead.
• Shim6 (140) has no entry in Internet.__proto__ (internet.py:92-118).

Expected: a header after a first fragment (offset 0) dissects the same way as it does without the Fragment header.

The packet bytes are in the #1535 review. This also affects round trips: the same TCP segment parses differently depending on a preceding fragment header.