MH._mh_option_length is short by 2 for all three CGA extension readers

[JarryShaw]

Found while sweeping comment/code drift after #509. Behavioural, not cosmetic — every parsed CGA extension reports a length 2 octets too small.

The contract and the violation

MH._mh_option_length (pcapkit/protocols/internet/mh.py:2719) returns schema_length + 2, and its docstring at :2744 states:

Returns:
Whole-option length, in octets, including the Type and Length fields.

+ 2 is correct for RFC 6275 §6.2 mobility options, whose Type and Length are 1 octet each. A CGA extension's are 2 octets each — pcapkit/protocols/schema/internet/mh.py:814-816:

type: 'Enum_CGAExtension' = EnumField(length=2, namespace=Enum_CGAExtension)
length: 'int' = UInt16Field()

Measured against 27bb315d5:

wire = 00120004 deadbeef     (8 octets, Opt Data Len = 4)
_mh_option_length(4)        = 6
fixed header for a CGA ext  = 2 (type) + 2 (length) = 4
correct whole-option length = 8
VERDICT: short by 2

Affected call sites

Three, all CGA-extension readers, all in pcapkit/protocols/internet/mh.py:

• :6239 _read_ext_none
• :6286 _read_ext_multiprefix
• :6331 _read_ext_exp

Provenance

The + 2 predates #509 — what #509 added was the docstring asserting a universal contract that three of its own callers violate. So this is not a regression introduced by that refactor, but the refactor is what made the inconsistency statable.

Suggested shape

The fix is almost certainly in the code rather than the docstring: either a separate helper for the 2-octet-header extension family, or a parameter for the fixed-header width. It wants its own test, since nothing currently asserts a CGA extension's reported length against the octets actually consumed.