refactor(vendor,pcapng): generate TLSKeyLabel from the RFC 9850 IANA registry

[JarryShaw]

Summary

Closes #886.

TLSKeyLabel moves from a hand-written class in pcapkit/protocols/misc/pcapng.py
to a generated one at pcapkit/const/pcapng/tls_key_label.py, crawled from the
IANA "TLS SSLKEYLOGFILE Labels" registry (RFC 9850 section 4.2), matching its
const/pcapng siblings' shape. RSA has no registry row (NSS-only, removed in
NSS 3.34) and is hand-carried by the crawler with its #883 comment kept
verbatim. Matching stays by uppercase value, not name, unchanged.

The canonical import path changes, per the owner's ruling on #886 ("go with
(1)"); pcapkit/protocols/misc/pcapng.py now re-exports the class under its own
name, so from pcapkit.protocols.misc.pcapng import TLSKeyLabel keeps working.

Two further public-contract effects breaking already covers but are worth
naming explicitly:

• Base class: the generated class derives from aenum.StrEnum (matching
  every other const/pcapng string registry) instead of
  pcapkit.utilities.compat.StrEnum. isinstance/issubclass against the
  compat class now returns False. repr, str, format, %-formatting,
  json.dumps, == 'ECH_SECRET', hash, isinstance(m, str), .value/.name
  are all unaffected — checked directly, not assumed.

• New API surface: mixing in EnumRegistry adds get/get_all/register/
  register_alias(es), which the hand-written class never had. No lookup path
  mints — T(...), .get(...), .get_all(...), T[...] on an unknown label
  all still raise/miss exactly as before — only the explicit T.register(...)
  grows the member set, which is the documented EnumRegistry contract.

• Searched for similar pull requests (fix(pcapng): repoint TLSKeyLabel at RFC 9850, add ECH_SECRET/ECH_CONFIG #883 is the related, already-merged one)

• Followed the coding style (pylint/mypy/isort run against the changed files; no new findings)

• 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?

• refactor — changes neither behaviour nor performance

Test plan

• Ran the crawler twice through the real pcapkit.vendor.__main__ entry point; byte-identical (sha256 9466eef...58446d) both times
• tests/protocols/misc/test_pcapng_unit.py — 94/94, extended with re-export identity + per-member value pins
• tests/const/test_const_enum_builtin_parity.py, test_const_enum_lookup.py, test_const_enum_get.py, test_const_enum_no_mint.py, test_const_registry_protocol.py — all green with updated sweep counts
• tests/vendor/test_vendor_missing_body_unit.py, test_vendor_dest_path_unit.py, tests/project/test_public_api.py, test_isort_clean.py — all green

[JarryShaw]

GOOD TO GO on 476fe923d — cross-review was opus (author sonnet). Its one blocking find is fixed, the CI failure is fixed, and I have re-run the affected files myself:

TREE /tmp/v890f/pcapkit/__init__.py
  test_const_registry_protocol.py     run=74 failures=0 errors=0
  test_const_enum_builtin_parity.py   run=33 failures=0 errors=0
  test_pcapng_unit.py                 run=94 failures=0 errors=0

The CI failure was one defect across five legs, not five: test_const_registry_protocol.py pins a population count over pcapkit/const and the new module made it stale — AssertionError: 122 != 121. A second sweep over the same population lives in that file, separate from the one in test_const_enum_builtin_parity.py that was already updated. pcapkit/const goes 139 → 140 .py files, so the +1 is exactly this change.

One judgement call in the fix, flagged rather than waved through. len(generated) deliberately stays 105, because the per-file loop at :790-796 asserts class \w+\(EnumRegistry, IntEnum\) — literally IntEnum — so a StrEnum file inside generated would fail that regex outright rather than just shift a number; and 105 is a historical census anchored at 05468a06b, which a later-added file was never part of. The arithmetic holds: 122 − 6 converted − 11 excluded = 105.

The cost is that tls_key_label.py now sits in EXCLUDED_STILL_BESPOKE, whose own comment describes modules that override the base's generic implementation, plus TransportProtocol for never mixing in EnumRegistry at all. This file fits neither — it mixes in EnumRegistry and overrides nothing. That is documented in a comment rather than hidden, and the alternative (widening the regex to admit StrEnum) would weaken the assertion for all 105 files, which is worse. @JarryShaw — if you would rather this were its own named frozenset, or the census anchored by sha instead of a live rglob, say so and I will have it split; I did not spin a third round for a naming preference.

The review's blocking find is also fixed: pcapkit/foundation/reassembly/data/data.py asserted TLSKeyLabel derives from compat.StrEnum, which this PR falsifies (issubclass(T, compat.StrEnum) goes True → False, since the generated file takes StrEnum from aenum as every other StrEnum const does). It now records the move explicitly and notes that json.dumps and string equality still hold while isinstance/issubclass against compat.StrEnum does not. The author's original report that the file "only names it in a docstring" was literally true and still missed it — a docstring can be a falsifiable claim about the thing you changed.

Two disclosure gaps closed in the PR body: the base-class move is a second public-contract effect beyond the import path (type identity flips; repr/str/format/%/json.dumps/==/hash/isinstance(m, str)/.value/.name all measured identical), and the class gains get/get_all/register/register_alias(es) from EnumRegistry where the hand-written one had none — additive, with only explicit register(...) able to mint. Nine lookup attacks left the member count at 11 throughout.

One latent crawler bug fixed unprompted: the citation builder matched \[RFC(\d+)\] with a '9850' fallback and appended #section-4.2 unconditionally, so a future row citing anything else would have silently got a false reference. It now anchors the match and raises on an unparseable reference. Output still byte-identical (sha256 9466eef…58446d) since all ten live rows are [RFC9850].

Determinism, RSA survival, uppercase values, WireGuardKeyLabel untouched, the registration pattern, the relocated autoclass, and all five parity counts were confirmed in the earlier review round and needed no rework. Unpublished and unmerged, yours to merge — it closes #886.

[JarryShaw]

added inline comment and synced from main branch

[JarryShaw]

GOOD TO GO on 7def2d117 — cross-review (opus; author sonnet), third head, parent re-confirmed as origin/main (fde4cb20c).

The Enum_TLSKeyLabel alias is in at :38 with TLSKeyLabel = Enum_TLSKeyLabel at :294 preserving the old path, and I measured the identity myself: from pcapkit.protocols.misc.pcapng import TLSKeyLabel is <canonical> → True, both module attributes resolving to the same object, WireGuardKeyLabel.__module__ still local. Tests on that head: test_pcapng_unit.py 94/0/0, test_const_registry_protocol.py 74/0/0, test_public_api.py 10/0/0. The 122 != 121 CI failure is gone.

The rebinding turns out to earn its keep in a way I had not considered. Because pickle's find_class does a plain getattr on the module, a stored pickle naming the pre-#886 location still resolves — verified:

cpcapkit.protocols.misc.pcapng\nTLSKeyLabel\n(S'ECH_SECRET'\ntR.
  -> <TLSKeyLabel.ECH_SECRET: 'ECH_SECRET'>   is canonical member: True

A bare import … as Enum_TLSKeyLabel with no rebinding would have broken every such pickle silently. It is the only module-level CapWords-to-CapWords rebinding in pcapkit/, so it is the odd pattern — but the alternatives are a reimport or an isort-hostile double alias, and it carries a comment explaining itself. Also checked: __module__ stays canonical so the const sweeps count it once; the docs use explicit autoclass and the block was relocated, so Sphinx is unaffected; __all__ is still ['PCAPNG'], unchanged from when the class was hand-written.

On EXCLUDED_STILL_BESPOKE, I was half wrong and am dropping the objection. I said the file fits neither of the set's stated rationales. In fact the name was already a misnomer before this PR: of the eleven entries, five already mix in EnumRegistry and three of those are already StrEnum. So the set's operative meaning is already "outside this file's IntEnum-only census", which is exactly what tls_key_label.py is — adding it is consistent with what the set does, not a new overload. And the second-frozenset idea I floated is worse: it would sort this one file honestly while leaving the other five misfiled. No change wanted here.

One pre-existing defect found, not this PR's. tests/const/test_const_registry_protocol.py:1536-1539 says its case is "synthetic, since no shipped aenum.StrEnum registry mixes in the base yet". I censused it independently: 10 shipped StrEnum registries mix in EnumRegistry — ftp.command.Command, ftp.command.FEATCode, http.method.Method, pcapng.option_type.OptionType, reg.apptype.AppType and its four transport subclasses, plus this PR's TLSKeyLabel. Nine of the ten predate #890, so the sentence was already false, and #890 only adds the tenth. Filing that together with the set rename as their own issue rather than widening this PR.

Unpublished and unmerged, yours to merge — it closes #886.