vendor(apptype): duplicated _missing_ range guards mint members with the wrong transport #760

Describe the bug

Two _missing_ range guards are duplicated, and the second copy of each is unreachable — so a minted member gets the wrong transport in its .proto.

Reproduction

Of 768 if guards in _missing_ (pcapkit/const/reg/apptype/apptype.py:2452-4765), exactly two conditions repeat:

• 6000 <= value <= 6063 at :2890 and again at :2893
• 6665 <= value <= 6669 at :3040 and again at :3043

The second copy is dead, so the first one's transport wins:

AppType.get(6010, proto='udp') -> <UDP.x11: 6010 [tcp]>

A member in the UDP registry claiming tcp-only.

Expected behavior

A member minted into the UDP registry for a UDP lookup should carry udp in .proto. Either the duplicate guards are merged with a combined transport, or the reachable one is chosen by the caller's transport rather than by source order.

System information

• OS Version: Linux 5.10 (Amazon Linux 2 int)
• Python Version: 3.14.7
• Python Implementation: CPython
• pcapkit Version: checkout at 932cb48d1

Additional context

Found while verifying #736 after #754. This is #736's "related, same area" note, now half fixed: the second call no longer raises TypeError — the minted member is in the owner's registry, so is holds — but the wrong .proto survives.

apptype.py is generated, so the fix belongs in the crawler (pcapkit/vendor/reg/apptype/), not in the emitted file. Note this interacts with #732's deferred TransportProtocol retype: if only declared values are accepted, a merged guard needs a named combination rather than an OR.