fix(reg): emit tcpdump legacy link-type names after current ones

[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 — 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

Closes #844.

LinkType(209).name returned 'IPMB_LINUX' — the name tcpdump and pcapkit's own generated
comment label "Legacy names (do not use)" — because that row was emitted above I2C_LINUX = 209
and aenum gives the value to whichever member is defined first. Introduced by cfdf2ab5c7
(2024-05-04), where a regeneration inserted the legacy row above the current one.

The fix is in the generator: pcapkit/vendor/reg/linktype.py now sinks any row whose note
column mentions "legacy" into a bucket appended after every current row, so the current name is
always defined first for a shared value. pcapkit/const/reg/linktype.py changes only as the
regenerated consequence — a 3-line move, verified byte-reproducible from the generator.

Verification, re-run by me on this rebased branch rather than taken from the worker's report:

LinkType(209).name        -> I2C_LINUX          (was IPMB_LINUX)
LinkType['IPMB_LINUX']    -> 209                (still reachable, as an alias)
LinkType['I2C_LINUX']     -> 209
members 220 / iteration 219                     (unchanged)
values with >1 name       -> {209: ['I2C_LINUX', 'IPMB_LINUX']}

• IPMB_LINUX is not removed — it stays an alias, so existing LinkType['IPMB_LINUX'] lookups keep working. Only the reverse direction changes.
• 209 is the only multi-name value in the table, so nothing else could have shifted; independently derived, not taken on trust.
• 'legacy' matches exactly one row in the whole generated table, so the rule is narrow today. It is deliberately a rule rather than a special case for 209, which means a future tcpdump row noting "legacy" would be sunk too — intended, and the reason the generator carries a comment saying so.
• Regenerating from this branch reproduces the committed const file byte-identically.
• coverage run -m pytest tests/const/ → 103 passed, 39458 subtests passed
• The new tests/const/test_const_linktype_209_unit.py against unfixed main → 3 failed
  ('IPMB_LINUX' != 'I2C_LINUX' on both lookups, plus the generator-ordering check)

Not breaking: no name disappears and no value changes; only the value→name direction for 209
starts returning the non-deprecated name, which is the defect being fixed.

[JarryShaw]

Python 3.11 failed, root-caused, and fixed — head is now f04a3431b. It was two symptoms of
one defect, not two failures:

FAILED tests/const/test_const_linktype_209_unit.py::LinkTypeGeneratorLegacyOrderingTests::test_both_rows_still_render_with_their_own_comment
FAILED …::test_current_name_is_emitted_before_the_legacy_one
  bs4.exceptions.FeatureNotFound: Couldn't find a tree builder with the features
  you requested: html5lib. Do you need to install a parser library?

The generator-level tests parse their fixture with bs4.BeautifulSoup(…, 'html5lib'). html5lib
ships as beautifulsoup4[html5lib] in the vendor extra (pyproject.toml:203), and the test
extra deliberately carries a plain beautifulsoup4 — pyproject.toml:256-263 says so explicitly. CI's
unit-tier job installs .[test,DPKT,crypto,NGAP], so the parser was never there. Same shape as
#511's ModuleNotFoundError: No module named 'requests', which is a vendor-extra dependency too.

Fixed with the repo's established guard, mirroring tests/protocols/test_dispatch_registry_unit.py:42:
a module-level HAS_HTML5LIB = importlib.util.find_spec('html5lib') is not None plus
@unittest.skipUnless on that one class.

The consequence, stated rather than buried: LinkTypeGeneratorLegacyOrderingTests is the
root-cause pin, and it now runs only where the vendor extra is installed — locally and in the
release gate, not in the unit-tier job. LinkType209ConstResolutionTests needs no parser, so the
symptom the issue actually reported stays guarded everywhere. Adding html5lib to the test extra is
the alternative and is your call — the same call #511 raised for requests.

Verified both ways before pushing:

• locally, html5lib present → 4 passed, all four tests still execute
• with html5lib hidden behind a patched find_spec → Ran 4 tests … OK (skipped=2), 0 failures, 0 errors
• isort --check-only clean

Amended into the single commit rather than stacked; no verdict had been issued on the old head, so
nothing is invalidated. review: pending stands and CI is re-running.

[JarryShaw]

My previous fix was wrong and the repo's own guard caught it. Head is now 88f52fd13.

f04a3431b went red on 10 legs — Python 3.10–3.14 and Engines Python 3.10–3.14 — with two
failures per leg, both one defect:

FAILED tests/test_tier_guard.py::DependencyGateCoverageTests::test_every_gate_a_job_reaches_has_its_dependency_installed
FAILED tests/test_tier_guard.py::DependencyGateFalsifiabilityTests::test_the_undoctored_workflow_produces_no_unexplained_gap
  AssertionError: Lists differ: [Gap(flag='HAS_HTML5LIB', job='gate', …)] != []

I introduced a new dependency gate, HAS_HTML5LIB, and tests/_dependency_gates.py requires every
HAS_* flag a job reaches to either have its dependency installed or carry an explicit exclusion. Mine
had neither. That is the guard doing exactly its job, on me.

The right fix was to mint no new gate at all. HAS_VENDOR_DEPS already exists for precisely these
dependencies — ('requests', 'bs4', 'html5lib'), spelled that way in
tests/vendor/test_request_prompt_unit.py:99,108 and four sibling files — and
tests/_dependency_gates.py:315 already accounts for it:

'HAS_VENDOR_DEPS': Exclusion(dark={'test': ('html5lib',), 'gate': ('html5lib',)}, reason=…)

with engine-tests closing the gate by installing the vendor extra. So the class now guards on
HAS_VENDOR_DEPS with the identical tuple, and needs no exclusion edit.

Net effect, which is better than my first attempt: the root-cause pin runs per-PR on engine-tests
rather than only locally, because that job installs vendor. test and gate stay dark on html5lib
by the existing ruling. LinkType209ConstResolutionTests needs no parser and still guards the reported
symptom on every leg.

Verified before pushing:

• tests/test_tier_guard.py — the guard that flagged me — 102 passed, 549 subtests passed
• tests/const/test_const_linktype_209_unit.py locally → 4 passed
• with html5lib hidden behind a patched find_spec → OK (skipped=2), 0 failures, 0 errors
• isort --check-only clean

Amended into the single commit; review: pending stands and no verdict was issued against either
superseded head.

[JarryShaw]

GOOD TO GO on 88f52fd13 — the cross-review (opus, a different model from the sonnet author) returned
NEEDS CHANGES for exactly one thing, the breaking label, and it was right. Applied, so the change it
asked for is done and nothing in the code needs touching.

I got the label wrong, and the reasoning is worth recording. I argued "no name disappears and no value
changes, only the value→name direction for 209". True, but it is a normative test — "the old output was a
defect, so changing it is not breaking" — and the repo's applied rule is descriptive: did observable
public output change? Verified myself on both trees:

main: LinkType['IPMB_LINUX'].name = 'IPMB_LINUX'    LinkType(209).name = 'IPMB_LINUX'
PR  : LinkType['IPMB_LINUX'].name = 'I2C_LINUX'     LinkType(209).name = 'I2C_LINUX'

So LinkType['IPMB_LINUX'].name == 'IPMB_LINUX' breaks in consumer code. And #847 carries fix,
breaking, const for the same shape of change — a name-resolution reordering in a generated const enum
where no value changes and no name disappears. I set that precedent three commits ago and then contradicted
it here.

What the review verified independently, each derived rather than read off the PR:

• the root cause is genuinely generator-level — proved the hard way: regenerating the base tree from
  its own unfixed generator reproduces the buggy const file byte-identically, so a regeneration without the
  vendor change reintroduces the inversion, exactly as reg: LinkType(209) resolves to IPMB_LINUX, the name tcpdump and pcapkit both label do-not-use #844 warned
• the full name → value map is identical across all 220 entries, with exactly one positional
  difference in 219 canonical slots (index 123); 209 confirmed the only doubly-assigned value, checked
  against the live registry's 205 rows as well as the committed table
• the 'legacy' rule matches exactly 1 row in a live fetch of tcpdump.org/linktypes.html
• byte-reproducible regeneration; tests/const/ 103 passed / 39458 subtests, re-derived as
  Ran 103 tests … OK under plain unittest; new file 3 failed on unfixed main, and it read all
  three rather than trusting the count
• the HAS_VENDOR_DEPS reuse is legitimate, not exclusion-borrowing — zero HAS_HTML5LIB entries
  remain, the new file adds a Gate to an already-existing (job, module) gap rather than widening or
  inventing one, and HAS_CRAWLER_DEPS would have been provably wrong (it resolves to ['bs4', 'requests'] with no parser, so the class would have run on test and died with the same
  FeatureNotFound the fix exists to prevent)
• the generator class genuinely runs per-PR: engine-tests installs the vendor extra and its three
  --ignore globs do not match this file, so it executes on all five legs

Three residual risks it raised as follow-ups rather than blockers — filed as #852 so they are not lost.