fix(mh): stop the four RFC-inline helper enums from minting on unassigned bytes

[JarryShaw]

Please follow the guide below

• Searched for similar pull requests
• Followed the coding style (make pylint, make mypy, make isort)
• make test passes, and a test case covers the change
• Added a changelog entry under docs/source/changelog/ and regenerated CHANGELOG.md -- N/A -- changelog centralised in docs(changelog): shared 1.5.0 changelog — long-lived, merges last (#610, #616, #617, #618, #620) #657

What is the purpose of your pull request?

• fix — corrects a defect

Description of your pull request and other information

This is the mh.py half of #880 only. ngap.py's ProcedureCode/ProtocolIE are the other two of the six sites #880 names, ruled to be sourced from pycrate through a vendor crawler instead (separate work), so #880 stays open.

Per the owner's ruling on #877, FastBindingAcknowledgmentStatus, IPv6AddressPrefixCode, LocalizedRoutingStatus and LMAAddressCode no longer mint an Unassigned_N member for a value their RFC leaves unassigned. _missing_ raises a new EnumValueError (pcapkit.utilities.exceptions, pairing with EnumError the way FieldValueError pairs with FieldError) instead -- no existing exception there fit "no member for this value in a closed enum".

get()'s default=-1 mint path -- the shared-sentinel aliasing defect #880 measured -- is removed for the two enums that keep get(); it now raises the same way _missing_ does. LocalizedRoutingStatus.get/LMAAddressCode.get are deleted outright, verified zero callers repo-wide, tests included.

The consequence of the raise differs by wrapping protocol, and this matters for anyone reading the diff. Over IPv4, which dispatches Mobility Header through the base, non-chain-walking _import_next_layer, the @beholder decorator there degrades just the one MH message to Raw -- not a capture-level failure. Over IPv6, Mobility Header is also one of IPv6's own chained extension headers, so the fallback lands inside IPv6's own extension-header walk, which then does proto = info.next (ipv6.py:338) on it; Raw's info has no .next, so that second, unrelated AttributeError is what a further-out @beholder actually catches -- degrading the whole IPv6 packet, header fields included. That walk defect is pre-existing (a truncated or malformed extension header hits the identical AttributeError on unmodified main), but this change adds a far likelier route to it: a well-formed packet naming merely an unassigned byte, where before only a malformed one got there. Sibling frames are unaffected either way.

Two tests pinning the old minting/round-trip behaviour are re-pointed; a new test proves the aliasing defect is gone and the 0 <= value <= 255 range invariant holds, demonstrates the IPv4 degrade path, and pins the IPv6 whole-packet-to-Raw behaviour as it stands today -- deliberately, so whoever fixes ipv6.py:338 sees that assertion and knows to revisit it. Each new/changed assertion is shown to fail without this fix.

tests/protocols/internet/test_mh_unit.py: 51 run, 0 failures, 0 errors.

[JarryShaw]

Qualifying something I told you when recommending the raise — the safety argument is verified on a path real captures do not take.

I said raising "costs one MH message's structured parse, not the capture", because the lookups sit under _import_next_layer, which is @beholder-decorated at pcapkit/protocols/protocol.py:1827 and re-parses the layer as Raw. #889 tests exactly that and it holds — for MH wrapped in IPv4 (tests/protocols/internet/test_mh_unit.py ~:1669, wrap_in_ipv4).

But Mobility Header is an IPv6 extension header; the IPv4 wrapping is a synthetic harness. And IPv6 does not merely hand the layer back — it keeps walking its own chain:

ipv6.py:329   info = next_.info          # next_ is the _import_next_layer result
ipv6.py:338   proto = info.next

Measured: Raw's info has no .next attribute (hasattr(...) → False). So a Raw fallback structurally cannot satisfy that walk, and #889's own test comment says as much — it chose IPv4 because of it.

What I have not established: I tried to reproduce the failure on unfixed main with a hand-built IPv6 header (next-header 135, 2-byte truncated MH) and it parsed fine — my packet never reached the extension-header walk. So the AttributeError: 'Raw' object has no attribute 'next' the author reports is plausible and structurally supported, but not reproduced by me, and I am not going to relay it as fact.

The cross-review's first task is to settle it on the PR head and to test whether main fails identically for an unrelated MH parse error — which decides whether this is pre-existing (the PR merely reaches it by a new route) or introduced here.

This does not change your ruling — the four enums should still raise, and the get(default=-1) aliasing defect is real either way. What it changes is the cost line. If the IPv6 walk really does break on the Raw fallback, then for the path real captures take a raise is not contained to one message, and that is a pre-existing gap in the degrade path worth its own issue rather than a reason to keep minting. I will report the measurement either way before #889 is handed over.

[JarryShaw]

GOOD TO GO on a47d23186 — cross-review was opus (author sonnet); the NEEDS CHANGES it raised was on the disclosure, and that is now fixed and verified.

The code was never in question. What was wrong is what the code said, in four shipping docstrings. Verified on the amended head:

"degrades just that one message"  ->  0 occurrences
"whole IPv6 packet"              ->  4 occurrences  (one per class)
EnumValueError docstring         ->  """No member of a closed enumeration carries this value."""  (one line, matching all 33 siblings)
run=51 failures=0 errors=0

Each of the four now cites ipv6.py:338 (proto = info.next on a Raw whose info carries no .next) as the mechanism, says the whole IPv6 packet degrades rather than the one MH message, and records that the walk defect predates this change — a well-formed packet naming an unassigned byte is simply a likelier way to reach it than a malformed one.

Three things the author did beyond what I asked, all right calls:

• Found a third site carrying the same false claim — test_mh_rfc5568_local_enums_cover_unregistered_value_sets's docstring at test_mh_unit.py:1444, not one of the six I listed. Now "one message's worth of damage over IPv4, the whole packet's over IPv6".
• Split the degrade test into two named subTests rather than relabelling one: 'over IPv4, an unassigned wire byte degrades just that one MH layer' (:1663) and 'over IPv6, the same raise costs the whole packet (pre-existing defect)' (:1701), the latter asserting str(eth.protochain) == 'Ethernet:Internet_Protocol_version_6'.
• Reproduced my measurement independently before editing, rather than taking the table on trust.

That IPv6 subTest is the part worth keeping: it pins today's defective behaviour as an explicit assertion, so whoever fixes #891 (the ipv6.py chain-walk, filed separately) breaks this test and is forced to look here rather than discovering the change by accident.

The earlier verdict's other findings stand confirmed and needed no rework: the four enums are correctly closed with extend_enum gone from all of them, EnumValueError is placed as the ValueError counterpart to EnumError per the FieldError/FieldValueError pairing and is explicitly sanctioned by #877's item-3 ruling, get()'s parameterless contract matches Criticality.get's precedent with zero affected callers, and the new tests genuinely fail without the fix — 7 failures + 1 error, reproduced exactly, now 8 with the IPv6 case added.

Still references #880 rather than closing it: ProcedureCode and ProtocolIE in ngap.py remain, per the ruling that they be sourced from pycrate through a crawler. CI is mid-run on the new head; I will confirm green before handing over. Unpublished and unmerged, yours to merge.