reg: LinkType(209) resolves to IPMB_LINUX, the name tcpdump and pcapkit both label do-not-use

[JarryShaw]

Found while researching #842's duplicate-value question. LinkType(209).name returns the
name upstream explicitly says not to use, and pcapkit's own comment on that member says so
too.

Measured on origin/main (6216de505):

pcapkit/const/reg/linktype.py:421   #: [``DLT_IPMB_LINUX``] Legacy names (do not use) for Linux I2C below.
pcapkit/const/reg/linktype.py:422   IPMB_LINUX = 209
pcapkit/const/reg/linktype.py:424   #: [``DLT_I2C_LINUX``] Linux I2C packets.
pcapkit/const/reg/linktype.py:425   I2C_LINUX = 209

IPMB_LINUX is declared first, so it becomes the canonical member and I2C_LINUX an
alias of it. Live:

LinkType(209).name     -> 'IPMB_LINUX'
LinkType['I2C_LINUX']  -> <LinkType.IPMB_LINUX: 209>

So even asking for the current name hands back the legacy one.

Upstream is unambiguous the other way. libpcap's pcap/dlt.h defines
#define DLT_I2C_LINUX 209 first, then explains: "This was renamed as it's also used for
other protocols, such as Display Data Channel as used by HDMI. We still define
DLT_IPMB_LINUX for backwards source compatibility." tcpdump.org/linktypes.html labels the
IPMB_LINUX row "Legacy names (do not use)". Wireshark drops the legacy name entirely —
epan/dissectors/packet-pcap_pktdata.c:174 has { 209, "I2C_LINUX" } only.

Cause is mechanical, and datable. The crawler reads linktypes.html row order
(pcapkit/vendor/reg/linktype.py:35) and has no alias or precedence logic. I2C_LINUX
landed first in 78ef9f7a89 (2024-04-27); a later regeneration, cfdf2ab5c7 (2024-05-04),
inserted IPMB_LINUX above it and silently flipped which name Python treats as
canonical. A regression introduced by regeneration, not by a hand edit.

Fix shape: the vendor module needs to emit the current name first when
linktypes.html lists a legacy row above it — or carry an explicit precedence override, since
row order demonstrably does not supply the answer. Regenerating without that change will
reintroduce it.

Separate from #842's register_alias design; this one is wrong regardless of which
convention wins there.

[JarryShaw]

Checkable blocker: #838 merged.

gh pr view 838 -R JarryShaw/PyPCAPKit --json merged -q .merged   # true == unblocked

Measured, not assumed: git diff --name-only add2a8255 eae67f6bd -- pcapkit/const/reg/linktype.py
lists the file, so #838 rewrites the very table this fix regenerates. Starting first means
rebasing onto a 220-member file that changed underneath.

Worth noting for whoever takes it: the fix belongs in pcapkit/vendor/reg/linktype.py, not in
the generated const file, and regenerating without the vendor change will reintroduce the
inversion — the crawler reads tcpdump.org/linktypes.html row order, which lists the legacy
IPMB_LINUX row above the current I2C_LINUX one. That is how cfdf2ab5c7 introduced it in
the first place. Regeneration is verifiable locally: the network is reachable and the generators
run, so a fix can be proved by regenerating and diffing rather than by hand-editing and hoping.

[JarryShaw]

#848 is review: good-to-go on 88f52fd13 and carries breaking — LinkType['IPMB_LINUX'].name changes
from 'IPMB_LINUX' to 'I2C_LINUX', which is a public-contract change by the same descriptive test #847 was
labelled against.

Three residual risks in the fix's 'legacy'-sink rule, raised by the cross-review as non-blocking, are filed
as #852 rather than folded in here: the predicate is not value-aware (so a future current row whose
notes mention "legacy" would invert #844 in mirror image), the USER0–USER15 range branch inherits the same
sink so one row could move sixteen members, and the generator comment claims a value-sharing check the code
does not perform.

None is live today — a live fetch of tcpdump.org/linktypes.html matches the rule on exactly 1 of 205 rows.