test(const): fix the stale StrEnum docstring and rename EXCLUDED_STILL_BESPOKE

[JarryShaw]

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

• test — tests only

---

Description of your pull request and other information

Closes #892.

Two stale-prose fixes in tests/const/test_const_registry_protocol.py, no behaviour change:

1. test_default_still_resolves_when_registered_str's docstring called its case "synthetic, since no shipped aenum.StrEnum registry mixes in the base yet". Measured independently by walking pcapkit.const for EnumRegistry+str subclasses: ten already do (Command, FEATCode, Method, OptionType, TLSKeyLabel, AppType and its four transport subclasses). Rewrote the docstring to state that instead.

2. EXCLUDED_STILL_BESPOKE's comment described "overrides the base" plus TransportProtocol for never mixing in at all — but most entries do mix in EnumRegistry. Renamed to EXCLUDED_FROM_INTENUM_CENSUS and re-grouped its eleven entries by which of three reasons actually applies (not an IntEnum; overrides the base; never mixes in the base — apptype.py carries two of the three in one file). return_code.py/status_code.py's actual override is a custom __new__ plus _unregistered_member, not get()/register(). Updated all four other references (one behavioural, three prose).

all_files/generated/exclusion counts (122/105/11, 6+11+105=122) are unchanged — this branch is now rebased onto #890 (parent commit), which added pcapkit/const/pcapng/tls_key_label.py and is what brought the census from nine to ten and the exclusion set from ten to eleven entries.

[JarryShaw]

Resolve conflicts.

[JarryShaw]

GOOD TO GO on 0ef615e7d — cross-review (opus; author sonnet). Its one blocking finding is fixed and I verified the corrected claim by method-resolution introspection rather than from the report:

                     get   register  _unregistered_member
ReturnCode           base    base     own
StatusCode           base    base     own
ResponseKind         base    base     base
GroupingInformation  base    base     base
FEATCode             base    base     base

So the old comment was wrong in both directions: get/get_all/register/register_alias are never overridden in those files, and the real override is _unregistered_member. The corrected text now says exactly that, and separates ReturnCode from ResponseKind/GroupingInformation, which are clean and excluded only as co-residents of return_code.py. Source confirms the __new__ half too — ReturnCode:95 and StatusCode:33 define one; ResponseKind:36, GroupingInformation:60 and FEATCode:26 do not.

One instrument error of mine worth recording, because it nearly produced a false contradiction. My first check used '__new__' in vars(cls) and reported True for all five, which would have made "are clean" wrong. Control: pcapkit.const.mh.packet.Packet, a plain generated registry with no source __new__, also reports True — the enum metaclass installs one on every enum class, so vars() cannot answer this question at all. The source grep can, and does.

The second item is fixed as well: the StrEnumValueFallbackTests sentence at :1176-1180 no longer claims those files are excluded for "bespoke __new__/get() shapes" — it now says they are StrEnum rather than IntEnum, "which is reason (a) there regardless of whether any one of them also overrides the base". That resolves the self-contradiction with the group (a) label, and stops being false about FEATCode.

Both non-blocking notes were folded in rather than deferred: :715-725 now states precisely which classes keep something bespoke (Command, Method, OptionType, plus ReturnCode/StatusCode for _unregistered_member only) against which resolve everything to the base (FEATCode, ResponseKind, GroupingInformation), and the apptype.py tag notes that AppType overrides all four more fully than either file actually tagged (b). The stale post-rebase PR description is updated — eleven entries, 122/105/11, 6 + 11 + 105 = 122, and the "pre-#890" framing dropped now that #890 is its parent.

Still one commit, one file, 74/74 and 33/33 green, and the earlier verification stands: the rebase lost nothing of #890's, every count re-derives, and the set's single operative use is the rename only.

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

[JarryShaw]

Rebased onto current main (ea5d34dc6) — 0ef615e7d → 098cb5120, still exactly one commit.

Needed because the main ruleset sets strict_required_status_checks_policy=true, so a BEHIND branch cannot merge until it is current. #893 merging as 486c2a269 put this branch behind.

The review: good-to-go verdict carries to the new head, and here is why that is not a rubber stamp. Before the rebase I merged 0ef615e7d into current main in a scratch worktree and ran the file it touches:

merge exit=0, 'ort' strategy, no conflicts
tests/const/test_const_registry_protocol.py | 130 +++++++++++++++++++---------
Ran 74 tests in 63.992s -- OK
TREE /tmp/verify894-b/pcapkit/__init__.py

The rebase produces the same single-commit diffstat (88 insertions, 42 deletions, same one file), so the tree I tested and the tree now on the branch are the same content. CI is re-running on 098cb5120; I will confirm it lands green before calling this ready.