MPTCP option header decodes length from bit offset 1 instead of 8, reading MP_CAPABLE as 60 not 12

[JarryShaw]

pcapkit/protocols/schema/transport/tcp.py:576 declares the generic MPTCP option header as:

test: 'MPTCPSubtypeTest' = ForwardMatchField(BitField(length=3, namespace={
    'length': (1, 8),
    'subtype': (16, 4),
}))

A TCP option header is kind (8 bits), length (8 bits), then the MPTCP subtype (4 bits) and flags. So length sits at bit offset 8, and the entry should be (8, 8). At (1, 8) it reads eight bits starting one bit in, straddling kind and length — for MP_CAPABLE it decodes the length as 60 instead of 12.

This is currently masked by an unrelated eool=0 check further along, which is why no test catches it. Same bug class as the SMF_DPD bit offset fixed in #432.

Found by a sweep of deferred work across this release's 68 merged PRs; the offset was never flagged in review.

Related, and worth fixing in the same pass

#541 is narrower than its title suggests. It covers TCP._make_mptcp_addaddr, one of eight MPTCP makers. EXPECTED_FAILURES in tests/protocols/test_option_roundtrip_unit.py holds 8 tcp-mptcp/* entries sharing the same kind=/length= rejection, and #430's review had already established the family-wide scope five days before #541 asked whether other _make_mptcp_* helpers did the same. Either widen #541 or fix the family here and close it.

Coverage

A test that decodes a real MP_CAPABLE option header and asserts length == 12. Prove it fails with (1, 8) and passes with (8, 8), reading the exit code from a file — pytest-subtests is not installed and pytest 9.1.1 prints a failing subtest's parent as PASSED.