fix(const): make every registry's register reject what its get rejects (#1816)

[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

---

Description

Closes #1816, and widens the scope to every enum per your note on #1818. Before this PR, EnumRegistry.register called the _validate_value hook, but only AppType overrode it. So Hardware.register(70000, 'x') would mint a member that Hardware.get(70000) then returned.

• Generators: each vendor template now emits a _validate_value override. It runs the same check the template already writes into _missing_ and raises EnumValueError with the same message.
  • The check is the crawler's FLAG, or the template's own range: 0-999 for StatusCode/ReturnCode, 0-9 for ResponseKind/GroupingInformation, str for the string-valued ones.
  • TLSKeyLabel and ExtensionHeader have no _missing_, so they get a type check and the 8-bit Next Header range (RFC 8200).
• Const files: re-rendered offline through each crawler's own template. An AST comparison against main shows that only the override, its imports and two docstrings changed, with no member data touched.
• Tests: a new test walks every registry at runtime. It checks that register raises if and only if get rejects, that the hook agrees with _missing_ on boundary values, and that no registered value is refused. It fails on main. The no-mint sweep now mints inside each registry's range.

Behaviour note: get(out_of_range, default) still returns default, but now also logs one CRITICAL EnumValueError and installs pcapkit's excepthooks; on main it was silent. The cause is that the hook raises a loud EnumValueError before get falls back to default, as #1818 already does for AppType. Measured: no parse path triggers it. Over the sample captures there are 0 hook rejections, and none of the library's registry .get() call sites passes a default or a value wider than its hook allows. A quiet=True error on the get path would remove the noise, as a follow-up if wanted.

Left alone:

• In-range gap values that get rejects but register may mint, such as CauseCode(0). These are documented in registry-protocol.rst.
• A pre-existing Command.get defect, filed separately.

Narrow runs, all passing:

• tests/const: 341 passed.
• tests/vendor: 142 passed.
• tests/corekit: 620 passed, 16 skipped.
• tests/project: 949 passed, 1 skipped.

[JarryShaw]

Verdict: NEEDS CHANGES at 020f2a92b. A Sonnet cross-review (the author was Opus) confirmed the substance:

• No member data changed. An AST diff of every changed const file against main is identical once imports, the new hooks and docstrings are set aside.
• Every crawler, re-run against live IANA data, renders byte-identical to the committed file.
• Every hook matches its _missing_ guard, and get is unchanged on boundary probes across all registries.
• The suites still pass.

Required: registry-protocol.rst:83 says "Two registries have no _missing_", which is a count in prose. The review also showed that the judgement-laden hooks are pinned by no test: ExtensionHeader's 255 bound, TLSKeyLabel's str check, and the 0..9 bound on ResponseKind and GroupingInformation. A fix round is under way.

[JarryShaw]

Verdict: GOOD TO GO at 5ca7d2db2. A Sonnet re-check (author: Opus) verified the fix round:

• The count is gone.
• All eleven mutations to the bounds and the return value now fail the new pin test.
• No parse path triggers a hook rejection, measured on this head against b7488c621:
  • Across the generated sample captures, 7057 hook calls produced 0 rejections and 0 new CRITICAL records.
  • The tests/protocols, foundation, interface, integration and toolkit suites log identical CRITICAL records on both trees.
  • None of the library's registry .get() call sites passes a default or a value wider than its hook.
• tests/const, tests/vendor and tests/project all pass.

The loud fallback for explicit out-of-range calls with a default is noted in the PR body.