fix(const): reject an out-of-range port in AppType.register (#1792)

[JarryShaw]

Please follow the guide below

• You will be asked some questions, please read them carefully and answer honestly

• Put an x into all the boxes [ ] relevant to your pull request (like that [x])

• Use Preview tab to see how your pull request will actually look like

• 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. Narrow runs only, listed below.

• Added a changelog entry under docs/source/changelog/ and regenerated CHANGELOG.md, if the change is user-visible: N/A — 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?

Tick the commit type your subject line carries.

• fix — corrects a defect
• feat — adds a feature
• perf — changes performance, not behaviour
• refactor — changes neither behaviour nor performance
• test — tests only
• docs — documentation only
• ci — workflows or build tooling
• release — bumps the version or rolls up a distribution
• chore — anything else

---

Summary

TCP.register(70000, 'x') minted a member, and so did -1, after which AppType.get(70000, proto=tcp) returned it, although get rejects an out-of-range port (#758). EnumRegistry.register validates through the _validate_value hook, but AppType neither overrode it nor called it.

• Fix: AppType._validate_value rejects anything that is not an int in 0–65535, the check _missing_ makes. register calls it, in the same order as EnumRegistry.register. The change is identical in the vendor template and the generated pcapkit/const/reg/apptype/apptype.py.
• Exception: per registry-protocol.rst, the hook raises EnumValueError, which derives ValueError, with the same message get uses for an out-of-range port. Owner note: as a pcapkit BaseError it is loud (CRITICAL log, excepthooks outside devmode), like EnumLookup.get's miss. The registry's other register refusals are still builtin ValueError.
• Tests: tests/const/test_const_apptype_register_range_1792_unit.py fails on main across TCP, UDP, SCTP and DCCP. A mutant raising builtin ValueError fails it too. tests/const, tests/vendor, tests/corekit and tests/project pass.
• No versionchanged: AppType had no register in 1.4.1.post2. The same gap in the other registries is fix(corekit): registries' register accepts values their get rejects #1816.

Closes #1792

[JarryShaw]

Verdict: GOOD TO GO at 38f55c043. A Sonnet review and two re-checks (author: Opus). On all four transports register now rejects an out-of-range port with EnumValueError and get's message, and 65535 still mints. Template parity holds over the whole file. The test fails on main and against a builtin-ValueError mutant, and the const, vendor, corekit and project suites pass. The loud-BaseError consequence is noted in the body for the owner.

[github-actions]

Coverage: 89.60% (unit tier, Python 3.15, 38f55c043, Unit Tests run success)

Package	Statements	Missed	Branches	Partial	Cover
pcapkit (top level)	104	3	20	3	95.16%
pcapkit/const	18868	954	2370	868	91.06%
pcapkit/corekit	2462	69	780	35	96.55%
pcapkit/dumpkit	276	3	100	3	98.40%
pcapkit/foundation	2915	164	1016	34	93.59%
pcapkit/interface	138	7	52	5	93.68%
pcapkit/protocols	17197	224	4580	189	98.09%
pcapkit/toolkit	872	177	298	8	77.18%
pcapkit/utilities	512	2	158	4	99.10%
pcapkit/vendor	4417	2342	1010	157	43.38%

Per-file detail: the coverage-html artifact of this run.

[JarryShaw]

Is this check needed for all other enums as well? I dont think register validate the input range at all.

[JarryShaw]

Yes, every other registry has the same gap, and you're right that register doesn't range-check anything today. EnumRegistry.register does call the _validate_value hook (pcapkit/corekit/enum.py:530), but the base implementation accepts everything and no generated registry overrides it.

I measured this just now on main: none of the 127 EnumRegistry subclasses define _validate_value, and Hardware.register(70000, 'x') mints a member that Hardware.get(70000) then returns.

This PR fixes AppType only (#1792). The rest is tracked in #1816, which is blocked until this PR merges because both touch the AppType const file and its generator. The proposed fix for #1816 goes in the vendor generators:

• emit a _validate_value override from the same range check each generator already writes into _missing_;
• regenerate the const files;
• add one test that every registry's register and get reject the same out-of-range value.

My recommendation is to merge this one as it stands and then do #1816. If you'd rather have it all in one PR, I can widen this one instead.