refactor(const,vendor): move the generated const-enum template onto EnumRegistry (#775)

[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, if the change is user-visible — 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?

• refactor — changes neither behaviour nor performance

---

Description of your pull request and other information

Tier 3 of #775/#842: mixes EnumRegistry into the generated const-enum template (pcapkit/vendor/default.py's LINE) and every const module it produces, so get/get_all/register/register_alias exist on all 121 const registries instead of 7.

Census, measured on 05468a06b (this batch's base): 121 const modules, 6 already carrying EnumRegistry (tier 1/2, #855), 111 carrying the literal generated get() docstring. Of those 111, 105 share the shared template byte-for-byte (verified against the template's own literal text) and are converted here; the other 6 plus reg/apptype's 4 transport subclasses (10 files total) are bespoke registries that don't share this template and are left alone — each carries its own __new__, see below.

This also closes the register() two-contract residue #855 disclosed: the generated register() used to silently alias an already-registered value rather than minting or raising.

Before: TransType.register(6, 'TOTALLY_NEW_NAME') -> <TransType.TCP: 6>, mints nothing, raises nothing
After:  TransType.register(6, 'TOTALLY_NEW_NAME') -> ValueError: 6 is already registered on TransType as 'TCP'; use TransType.register_alias() ...

get() dispatch matrix (old: isinstance(key, int) first; new/base: isinstance(key, str) first) — measured on TransType, an IntEnum registry:

key	before	after
valid int value	resolves	resolves (unchanged)
valid name	resolves	resolves (unchanged)
missing name	KeyError	KeyError (unchanged)
missing int	ValueError	ValueError (unchanged)
neither int nor str (3.5, None, b'x')	KeyError (treated as name)	ValueError (treated as value, via _missing_'s own int check)

Only the last row changes, and only for a key type nothing in the library ever passes.

StrEnum decision: excluded from this tier. None of the 105 in-scope files are StrEnum. The excluded ten are excluded because each carries a bespoke
__new__, not because they are all StrEnum — measured, only ftp/command.FEATCode, http/method.Method,
pcapng/option_type.OptionType and reg/apptype.AppType are StrEnum, while ftp/return_code.ResponseKind,
ftp/return_code.GroupingInformation, http/status_code.StatusCode are IntEnum and ftp/command.CommandType is
IntFlag. Each already has its own bespoke, mint-on-lookup contract from a crawler that overrides process()/context() outright, so none of them share vendor/default.py's template at all. Measured directly on a synthetic EnumRegistry+StrEnum registry (present on main since tier 1) that the base get()'s str-key path never falls back to a value lookup — a real, pre-existing limitation, not something this tier introduces — so converting any of those five/six would silently regress a value lookup rather than just relocate behaviour.

Regeneration: hand-edited the 105 files mechanically (script-derived from the template's own get/register/_unregistered_member text), then regenerated 5 live from IANA/Wikipedia — arp/hardware (IntEnum, drops the now-unused extend_enum import), sctp/cause_code, hip/parameter (crawler-overridden process(), many extend_enum ranges), pcapng/record_type (crawler-overridden, single legacy mint), reg/ethertype (57 extend_enum call sites) — all five came back byte-identical to the hand-edit (diff clean).

Tests: extended tests/const/test_const_registry_protocol.py with the 105-file sweep (base declared + inherited + no local copy, full corpus accounted for at 121 = 6 + 10 + 105), the register() regression pin (fails on 05468a06b, passes here), a _missing_ range-parity pin, the get() dispatch matrix above, and the StrEnum limitation measurement. tests/const/test_const_enum_get.py's vendor-template regression test asserted on the now-removed get() block text; rewritten to assert the mix-in and the absence of a shadowing local copy instead — the previously-named test_const_enum_builtin_parity.py/test_const_enum_lookup.py were checked too but don't actually depend on this template's shape (they cover the bespoke mh/tcp.flags/ftp/http templates instead), so they're unchanged.

_missing_ is untouched everywhere, per its own per-registry bounded ranges.

Test plan

• python -m unittest discover -s tests/const — 159 tests, all pass
• python -m unittest discover -s tests/vendor — 86 tests, all pass
• python -m unittest tests.test_tier_guard — 107 tests, all pass
• New register()-raises test: fails on 05468a06b (base), passes on this head
• isort -l100 -ppcapkit, mypy, pylint (Makefile flags) clean on all 105 const files + vendor/default.py — pylint duplicate-code findings on this batch drop from 108 to 4
• 5-file live regeneration sample byte-identical to the hand-edit

[JarryShaw]

One small note: forgot to mention previously, but I'd prefer the module name to be pcapkit.corekit.enum (no -s)

[JarryShaw]

Recorded, verbatim: "One small note: forgot to mention previously, but I'd prefer the module name to be
pcapkit.corekit.enum (no -s)"

Doing it here, and the measurement is why:

importers of pcapkit.corekit.enums on main : 17
importers on this PR's head                : 124   <- this PR's own 105 converted registries

This PR already touches 105 of the 124, so the rename is nearly free inside it. Doing it as a separate PR means a
second pass over the same 105 files and a guaranteed conflict with this one.

No shadowing risk, checked rather than assumed: enums.py's only third-party import is
from aenum import extend_enum — it never imports stdlib enum — and Python 3's absolute-import default means
pcapkit/corekit/enum.py cannot shadow stdlib enum for any other module either. No pcapkit/corekit/enum.py
exists today.

The worker is on it: git mv, then the 124 import sites, pcapkit/corekit/__init__.py's re-export, the tests, and
any docs/ cross-reference. I will verify the rename is pure — that the only change is the module path, with
no content drift — before this goes back to review.

One consequence worth stating: the cross-review currently running is against d91aaf30f, and its findings are
about get/register semantics, which a rename does not touch. So that verdict still applies; I will re-verify
only the rename on top rather than paying for a second full review of the same 100-file diff.

[JarryShaw]

GOOD TO GO on 86dcb375c — cross-review (opus, a different model from the sonnet author). No code defect
found. Two non-code items it raised are now done: breaking applied, and the body's StrEnum rationale
corrected.

breaking applied, and backfilled onto #855. The get exception-type change alone would not earn it; the
register() change does. Measured on two of the 105, and the old behaviour was worse than "returns silently" —
it actually installed the alias:

main  TransType.register(6, 'TOTALLY_NEW_NAME') -> <TransType.TCP: 6>   'TOTALLY_NEW_NAME' in __members__: True
head  TransType.register(6, 'TOTALLY_NEW_NAME') -> ValueError: 6 is already registered on TransType as 'TCP';
                                                   use TransType.register_alias() ...           in __members__: False

register is a documented public classmethod on 105 public pcapkit.const classes, so a downstream consumer using
it as an aliasing shortcut breaks on upgrade. The in-repo caller audit came back clean — 3 call sites, all in
tests/const/, all written for this change — but that protects this repository, not its users, and is not the
test. #855 shipped the identical semantic for 6 classes unlabelled, so I have backfilled breaking there too
rather than leave the two inconsistent.

Body corrected. It claimed the excluded ten are "all StrEnum-based". Measured: only ftp/command.FEATCode,
http/method.Method, pcapng/option_type.OptionType and reg/apptype.AppType are StrEnum;
ftp/return_code.ResponseKind, ftp/return_code.GroupingInformation and http/status_code.StatusCode are
IntEnum, and ftp/command.CommandType is IntFlag. The exclusion decision is right — each carries a
bespoke __new__ — but the stated reason was wrong for four classes, and that paragraph is what a future
maintainer reads to know why they were left out.

Three of my own claims were refuted, and all three matter:

• The diff is 124 files, not 100. gh pr view --json files silently caps at 100; gh api .../files --paginate
  and git diff --numstat both give 124, +779/−7170. My earlier "100 files, +321/−6721" was an API artefact.
• Three methods were removed per module, not two — _unregistered_member as well as get and register. Safe,
  because the base supplies it, but my brief undercounted.
• No IntFlag exists among the 105. All five EnumRegistry, IntFlag classes are the mh/*_flag and
  tcp/flags ones feat(corekit): add EnumRegistry base for const registries, convert 5 (#775) #855 already converted; the one bare IntFlag is ftp/command.CommandType, excluded. So the
  IntFlag matrix I asked for was not constructible.

What was confirmed, by AST comparison of all 121 const modules on both trees rather than by grep:
105 ['IntEnum'] -> ['EnumRegistry', 'IntEnum'], 0 methods added, 0 member-count deltas, 0 structural surprises,
and — the check that matters most — 0 source differences across every surviving method in all 105 files, md5'd
per method. _missing_ is byte-identical everywhere. The template's new conditional extend_enum import is correct
in all 105: every module whose _missing_ uses it still imports it, none that doesn't imports it unused.

The get matrix: 11 of 13 cells identical, 3 changed and only in exception class (KeyError → ValueError for
a key that is neither int nor str). No cell went from raising to returning or back, none returned a different
member, and supplying a default makes even those three identical.

Regeneration proven live on 3 of the author's 5-file sample against upstream: md5s differ only by two lines per
file that are an artefact of the reviewer's own python -m invocation (.. module:: __main__); filtering those
leaves zero changed lines — including the two interesting cases, arp/hardware (no extend_enum, import
correctly dropped) and reg/ethertype (57 sites, import correctly kept).

No stdlib shadowing from the rename, verified in one process: stdlib enum and pcapkit.corekit.enum are
distinct objects with distinct __file__s, sys.modules['enum'] is stdlib, and test_const_enum_builtin_parity.py
— which uses stdlib enum.IntEnum as its reference — passes 32/32. Shadowing only occurs if pcapkit/corekit/
itself is put on sys.path, which would already break every absolute pcapkit. import, and the repo already ships
11 other stdlib-name collisions (corekit/io.py, utilities/logging.py, corekit/fields/numbers.py, …).

One thing worth knowing that is out of scope here: 83 of the 105 still mint via extend_enum inside
_missing_, so get(148) grows the registry on both trees. #775's "no mint on lookup" goal is met only for the
21 modules using _unregistered_member. Unchanged by this PR, but it means the goal is not yet achieved
tree-wide — that is the next tier, not a defect here.

tests/const 159, tests/vendor 86, tests/test_tier_guard.py 107 — all OK under plain unittest, matching the
author's counts.