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.