reg: minted AppType members carry TransportProtocol.undefined, not their registry's transport

[JarryShaw]

Describe the bug

AppType._missing_ mints span members carrying TransportProtocol.undefined rather than the registry's own transport, so #806's guarantee — every member's proto names the registry it lives in — holds for declared members only.

pcapkit/const/reg/apptype/apptype.py:2272   __transport__: 'TransportProtocol' = TransportProtocol.undefined
pcapkit/const/reg/apptype/apptype.py:2296   proto: 'TransportProtocol' = TransportProtocol.undefined
pcapkit/const/reg/apptype/apptype.py:2427   proto: 'TransportProtocol | str' = TransportProtocol.undefined

Expected behavior

A member minted into TCP carries proto == TransportProtocol.tcp, the same as a declared one — so member.proto is cls.__transport__ holds for every member without qualification.

Additional context

Pre-existing, not introduced by #815, and #815 deliberately left it alone as out of scope. Found by #815's own author while proving the retyping, and recorded here so the qualification is tracked rather than implied: #815's new test_every_member_renders_its_own_registrys_transport_protocol covers the 12,391 declared members and says nothing about minted ones.

Note :2427's annotation is still 'TransportProtocol | str', which is the string-name form #815 removed from register_apptype — so if names are being rejected across the API, this is a second site to settle, and if they are being kept, this one already supports them. That makes this issue adjacent to the open question on #815 rather than fully independent.

Two traps for whoever takes it:

• The minting path is the one that produced Profile by self time: aenum.extend_enum is 16.7% of extraction, dispatch and imports under 1% #575's and fix(reg)!: reject an out-of-range port in AppType.get, and claim each span by transport #764's defects, so read those before changing it — a mint that gets the transport right but the bounds wrong is a worse outcome than the current honest undefined.
• Re-derive every line number against origin/main. feat(reg)!: retype AppType.proto to its own transport, and give register_apptype varargs (#806) #815 rewrites this file wholesale (+16/−14 in apptype.py, +5293/−5292 in tcp.py), so citations here go stale the moment it merges.

Related: #806, #815, #809, #575, #764.

[JarryShaw]

Checkable blocker: #815 merged.

gh pr view 815 -R JarryShaw/PyPCAPKit --json state,mergedAt

#815 rewrites the file this issue cites — const/reg/apptype/apptype.py — and its four sibling registries, so every line number above goes stale on merge and any edit here would collide. #815 is review: good-to-go with one open question on transport-name support, so the hold should be short.

Settle it together with that question if you can. :2427's annotation is still 'TransportProtocol | str' while #815 removes the string form from register_apptype; whichever way that lands, this site should match rather than diverge.

[JarryShaw]

Checkable blocker: #775 resolved.

gh issue view 775 -R JarryShaw/PyPCAPKit --json state

Unblocked from #815 by its merge (3118ed796), but this issue is downstream of #775, not independent of it. #816 is that minted AppType members carry TransportProtocol.undefined instead of their registry's transport — and #775 is that unrecognised values should not be minted into permanent members at all, per the maintainer's ruling quoted there: "so that we dont create registered enums out of unrecognised/unregistered values, unless user/caller explicitly created them."

If #775 lands as ruled, there is no minted member left to carry the wrong proto, and this issue dissolves rather than being fixed. Fixing it first would build a correct proto onto members that are about to stop existing.

So: sequenced behind #775, and likely to close with it rather than needing its own change. Re-examine when #775 resolves rather than assuming it is still live.

[JarryShaw]

Re-examined now that #775 has resolved, and it dissolved exactly as predicted above. Measured on main at 6102bf43f in a clean scratch worktree, with the tree under test asserted and printed:

TREE /tmp/m816/pcapkit/__init__.py
AppType.get(9999,  proto=tcp ) -> TCP.distinct   proto=<TransportProtocol.tcp: 1>   registered=True
AppType.get(9999,  proto=udp ) -> UDP.distinct   proto=<TransportProtocol.udp: 2>   registered=True
AppType.get(65000, proto=sctp) -> SCTP.unknown   proto=<TransportProtocol.sctp: 3>  registered=False

The third row is the case this issue was about — a value with no IANA assignment. It now comes back unregistered (registered=False, absent from __members__) and its proto is its own registry's transport, not TransportProtocol.undefined. The first two are real declared members, shown for contrast.

So there is no minted member left carrying the wrong transport: #874 gave AppType an _unregistered_member override that reconstructs svc/port/proto from the branch it came from, and #878 finished the conversion so nothing in pcapkit/const/ mints on a lookup miss except the documented CGAType carve-out. The defect had no separate fix; it stopped existing when the member stopped being created.

Closing, blocked removed. Worth recording why this was sequenced rather than fixed: building a correct proto onto members that were about to stop existing would have been work thrown away — the blocker comment above called that in advance, and it held.