reg: three Socket._missing_ range branches are unreachable, shadowed by a wider earlier branch

[JarryShaw]

Found while censusing the _missing_ range branches for #775. Pre-existing —
not introduced by #838.

Socket._missing_ tests its range branches in source order and returns on the
first match, so three branches can never be reached:

shadowed branch	range	shadowed by
pcapkit/const/ipx/socket.py:147 Experimental	0x0020-0x003F	:144 Registered by Xerox, 0x0001-0x0BB8
:153 Dynamically Assigned Socket Numbers	0x4000-0x4FFF	:150 Dynamically Assigned, 0x0BB9-0xFFFF
:156 Statically Assigned Socket Numbers	0x8000-0xFFFF	:150, same

Measured on dd9eee846:

Socket(0x0030)  ->  'Registered by Xerox_0x0030'      # expected Experimental_0x0030

pcapkit/vendor/ipx/socket.py:240 already carries a comment noting the branches
are tested sequentially, but treats that as a description rather than a defect.

The root cause is in the vendor crawler, which emits the branches in IANA row
order rather than narrowest-range-first, so the fix belongs there and the const
file is regenerated from it. Worth checking whether any other registry with
overlapping published ranges has the same shape — this one was found by
inspection, not by a sweep.

Note the three shadowed names are also exactly the kind the #838 discussion is
about, so whichever way the mint/no-mint classification lands, these branches
need to be reachable before that classification means anything here.

[JarryShaw]

Checkable blocker: #838 merged. Not the fix itself — the PR.

gh pr view 838 -R JarryShaw/PyPCAPKit --json merged -q .merged   # true == unblocked

#838 already modifies pcapkit/const/ipx/socket.py (verified:
git diff --name-only origin/main <838-head> -- pcapkit/const/ipx/ lists it), so a
branch for this fix cut from main would conflict on the same file. The work is
therefore being prepared on top of #838's head and the PR is held until that lands,
rather than stacking a review on an unmerged branch.

Also worth recording for whoever picks this up: the fix belongs in
pcapkit/vendor/ipx/socket.py, which emits the branches in IANA row order. The const
file is its output. Regeneration needs the network — Vendor.__init__ calls
self._request() unconditionally — so this is a hand-edit plus a rendered-template
equivalence proof, the same approach #838 used.

The mint/no-mint classification for these three branches is not part of this fix.
That is the #775 tier-2 decision ("decide from raw IANA row, not at runtime"); making
the branches reachable has to come first, or the classification has nothing to act on.

[JarryShaw]

As mentioned in #847

Should experimental and dynamically assigned actually be considered as same category of unassigned/reserved? Meaning we don't mint them to the class with extend_enum.

[JarryShaw]

Answered on #847 about 30 seconds before this landed, so you may not have seen it —
the measurement is here.
Short version, plus the part that is specific to this registry, which is the one where the
distinction actually bites.

Yes for experimental, no for dynamically assigned — and #838 already set the precedent, routing
Unassigned ×43, Reserved_for_Private_Use ×4, Reserved ×1 and Deprecated ×1 through
_unregistered_member rather than minting. Reserved_for_Experimental_Use and
Reserved_for_Testing_Purposes_Only still mint and belong in that same batch.

ipx/socket is the awkward one because it is the only registry whose range descriptions carry no
Unassigned at all, and the only vendor module with a module-level RANGES table. Of its five:

range	description	fold into _unregistered_member?
0x0020–0x003F	Experimental	yes — same "no defined meaning" category
0x0001–0x0BB8	Registered by Xerox	no — a positive statement about who registered it
0x4000–0x4FFF	Dynamically Assigned Socket Numbers	no — says who assigns, not that nothing does
0x8000–0xFFFF	Statically Assigned Socket Numbers	no — same
0x0BB9–0xFFFF	Dynamically Assigned	no — same

One concrete coupling worth knowing before you merge #847. Folding Experimental in would change
Socket(0x0030) from a minted member named Experimental_0x0030 to an unregistered member carrying
that description — so #847's test_previously_shadowed_ranges_are_reachable, which pins exactly that
name, would need updating in the same change. That is a reason to do it as the follow-up rather than
fold it into #847, not a reason to hold #847: the branch ordering this PR fixes is required either way,
since the first matching range still decides which description a value gets, minted or not.

Carried into #775 tier 2 rather than opened as a separate issue. Say the word if you would rather it
were its own.