reg: drop TransportProtocol's IntFlag base once nothing builds a composite

[JarryShaw]

Is this a bug or a feature request? A refactor, ruled on in #801.

Step 3 of #801's three, and the one that makes the maintainer's observation literally true:

the Flag type might be useful when doing register_apptype but its not used in other places. so we might actually just make the function signature as register_apptype(port: int, name: str, *transport: TransportProtocol) so that we can supply a list of transport without having to maintain a Flag for it

What changes

TransportProtocol stops being an IntFlag and becomes a plain IntEnum, once #806 has removed the last thing that constructs or consumes a composite.

Expected behavior

No bit arithmetic anywhere on TransportProtocol; auto() numbers members sequentially instead of by powers of two; the three Flag-only mechanisms below are gone rather than dormant.

Additional context

His claim is very nearly true today and becomes exactly true after #806. An AST sweep over every .py under pcapkit/, tests/, examples/ and docs/ found zero uses of &, ^ or ~ on TransportProtocol — only |, and only for construction, never masking. So nothing positively uses Flag semantics; every multi-bit use is either "the generator builds one" or "a guard detects and rejects one".

Three sites rely on Flag-ness outside register_apptype, and all three are dead after #806:

1. TransportProtocol._missing_ — pcapkit/const/reg/apptype/apptype.py:69-94, mirrored in the vendor template. Range-checks 0 <= value <= max(cls.__members__.values()) * 2 - 1 then defers to super()._missing_(value), which is aenum composing arbitrary bit combinations into pseudo-members (TransportProtocol(3) → tcp|udp). Intrinsic Flag machinery, existing only to support composites.
2. TransportProtocol.get() — apptype.py:64, extend_enum(TransportProtocol, key.lower(), max_val * 2). Assumes power-of-two numbering; meaningless under a sequential IntEnum.
3. _dispatch's rejection guard — show_flag_values(proto) then if len(namespaces) > 1: raise ProtocolError. Becomes unreachable once nothing can build a composite. Note show_flag_values itself (pcapkit/utilities/compat.py:196, a backport of 3.11's enum.show_flag_values) must stay — pcapkit.const.tcp.flags.Flags also uses it, tested at tests/dumpkit/test_nameless_enum_rendering_unit.py:168.

The generated const files currently carry 10,792 | constructions across const/reg/apptype/{tcp,udp,sctp,dccp}.py — e.g. reserved_0 = 0, 'reserved', TransportProtocol.tcp | TransportProtocol.udp. Those disappear in #806 when the generator stops emitting them, which is why this issue must follow rather than lead. Under a plain IntEnum, A | B falls through to int.__or__ and yields a bare int, so proto.name then raises AttributeError — a silent-looking failure if any | survives.

Use an AST sweep, not grep, to confirm nothing is left. A | between enum members can span a continuation line; a one-line grep produced a wrong count of 6 where the truth was 13 on #796. And self-test any pattern against a known-positive before trusting a zero — five zero-results in this project have turned out to be artefacts of the probe rather than facts.

Tests that pin the composite behaviour and must change with #806, not here — listed so this issue is not blamed for them: tests/const/test_const_apptype_split_unit.py:80, and tests/foundation/registry/test_protocols.py:476/:484/:493/:499.

Related: #801, #806, #807.

[JarryShaw]

Checkable blocker: #806 merged.

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

Until #806 lands, the generated const files still carry 10,792 TransportProtocol.a | TransportProtocol.b constructions, and all three Flag-only mechanisms above are still live. Dropping the IntFlag base first turns every one of those into a bare int whose .name raises AttributeError — 10,625 members broken at import.

Chain: #803 → #806 → this issue (and #806 → #807 in parallel).