docs: #1103 round 8 -- finish the Protocol/ProtocolBase cross-reference sweep, fix other prose drift (#2428)

Round 8 of the whole-repo prose sweep (#1103). Fanned out 8 shard agents by
directory; most of the repo was clean. Changes:

* pcapkit/protocols/internet/ipv6_ext.py + its .rst: finish the carry-over
  miss from round 7 -- the `_lookup_next_layer` plain pointer still targeted
  `ProtocolBase`, flipped to `Protocol` per #2420's ruling.
* Same miss in corekit/sentinels.py (`__keywords__`), docs/source/ext.rst
  (three sites, including a verbatim twin of a paragraph #2420 already fixed
  in protocol.py), schema/schema.py and schema/link/ethernet.py.
* internet.py, link.py, transport.py, sctp.py, protocol.py: `register()`'s
  Arguments: and a couple of Returns:/versionchanged clauses said `Protocol`
  subclass/instance while the signature types `ProtocolBase` and the
  adjacent Raises: clause already said so -- internal contradiction, fixed
  to `ProtocolBase` to match.
* docs/source/contributing/conventions/protocol-layer-placement.rst: the
  Link-Application-ProtocolBase set difference is `__proto_key__`, not
  empty as claimed (#2343 added it after this page was written).
* docs/source/contributing/conventions/registry-protocol.rst: "every
  registry overrides `_validate_value`" contradicted its own next
  paragraph, where the AppType transports inherit rather than override.
* pcapkit/vendor/ipx/packet.py, vendor/reg/linktype.py: a self-contradicting
  claim and a stale counted-number, both in vendor docstrings.
* docs/source/engines.rst, docs/source/conf.py, util/changelog_md.py,
  CONTRIBUTING.md: a stale scapy version, a wrong file path, a false
  "matches the Sphinx we build with" claim, and a missing caveat about
  actionlint making Lint non-advisory.

No executable code changed -- every edit is inside a docstring, comment, or
.rst file; confirmed by diff review and `import pcapkit` from this worktree.

Four behavioral defects found but deliberately left unfixed (reported
separately): 16 of 24 pcapkit/vendor crawlers' `process(self, data)` reads
the module-global `DATA` instead of its own `data` argument (latent,
harmless only because `request()` returns that same global); an empty
`FilterType` registry behind a live TODO; three open "handle this
programmatically" TODOs in pcapkit/vendor/mh; and dead `multiprocessing.Pool`
scaffolding in vendor/__main__.py.

Author: JarryShaw

CONTRIBUTING.md

@@ -163,9 +163,15 @@ header records which of them are clean and what each of the others would need be
 `continue-on-error` line could be deleted. Read the job's run summary, where each step writes
 its verdict, and try not to add to the numbers.
 
-`isort` is the exception: no `Lint` step runs it. It appears in `cron-vendor.yml` as a formatter
-that rewrites the regenerated constants, and `tests/project/test_isort_clean.py`, which the `test`
-extra's `isort` lets run, fails on a file whose imports `make isort` would reorder.
+**The job is not entirely advisory, though.** It carries one more step, `actionlint`, which lints
+the workflow YAML rather than `pcapkit/`, and that one has no `continue-on-error` and no
+`Makefile` target — so a change under `.github/` can turn `Lint` red even though none of the
+linters above can. The header records that split, and asks for a promoted step to be moved below
+the advisory ones, since a failed step skips every step after it.
+
+`isort` is absent from the job altogether: no `Lint` step runs it. It appears in `cron-vendor.yml`
+as a formatter that rewrites the regenerated constants, and `tests/project/test_isort_clean.py`,
+which the `test` extra's `isort` lets run, fails on a file whose imports `make isort` would reorder.
 
 One trap: `make vermin` redirects its report into `temp/vermin.txt` rather than to your terminal,
 so when vermin finds code that misses `vermin.ini`'s `targets = 3.8` and exits 1,

docs/source/conf.py

@@ -183,7 +183,7 @@
 # Those packages are therefore linked to their project pages instead, through
 # :data:`rst_epilog` below (#1936).
 
-#: The label on the note in :file:`pcapkit/foundation/engines/3rdparty.rst` that
+#: The label on the note in :file:`docs/source/pcapkit/foundation/engines/3rdparty.rst` that
 #: says which distribution installs the ``pcap`` module, which ``|pcap|_`` links
 #: to (:issue:`1948`).
 PCAP_MODULE_LABEL = 'pcap-module'

docs/source/contributing/conventions/protocol-layer-placement.rst

@@ -191,20 +191,26 @@ Counting the names in each class's own namespace, whether new or overriding
 :class:`~pcapkit.protocols.protocol.ProtocolBase`'s, and including those
 :meth:`ProtocolBase.__init_subclass__ <pcapkit.protocols.protocol.ProtocolBase.__init_subclass__>`
 sets there, :class:`~pcapkit.protocols.link.link.Link` has ``__data__``, ``__layer__``,
-``__post_init__``, ``__proto__``, ``__schema__``, ``_read_protos``, ``_shipped_proto``,
-``from_data``, ``register`` and ``layer``, and
+``__post_init__``, ``__proto__``, ``__proto_key__``, ``__schema__``, ``_read_protos``,
+``_shipped_proto``, ``from_data``, ``register`` and ``layer``, and
 :class:`~pcapkit.protocols.application.application.Application` has what they share
 (``__data__``, ``__layer__``, ``__post_init__``, ``__schema__``, ``from_data``, ``layer``)
 plus ``__index__``, ``_decode_next_layer`` and ``_import_next_layer``.
 :class:`~pcapkit.protocols.link.link.Link` overrides names that
 :class:`~pcapkit.protocols.application.application.Application` does not -- ``__proto__``,
 ``register``, ``_read_protos`` and ``_shipped_proto``, the last set because
-:class:`~pcapkit.protocols.link.link.Link` defines its own ``__proto__`` -- but each also
-exists on :class:`~pcapkit.protocols.protocol.ProtocolBase`, so the strict difference
+:class:`~pcapkit.protocols.link.link.Link` defines its own ``__proto__`` -- and each of
+those also exists on :class:`~pcapkit.protocols.protocol.ProtocolBase`, so each still
+resolves on :class:`~pcapkit.protocols.application.ospf.OSPF`. The strict difference
 :class:`~pcapkit.protocols.link.link.Link` minus
 :class:`~pcapkit.protocols.application.application.Application` minus
-:class:`~pcapkit.protocols.protocol.ProtocolBase` is **empty** and every one of them still
-resolves on :class:`~pcapkit.protocols.application.ospf.OSPF`. What changes is which
+:class:`~pcapkit.protocols.protocol.ProtocolBase` is ``__proto_key__`` alone
+(:issue:`2343`), which :class:`~pcapkit.protocols.link.link.Link` declares and neither of
+the others does, so it does **not** resolve on
+:class:`~pcapkit.protocols.application.ospf.OSPF`. Nothing turns on that:
+:func:`~pcapkit.foundation.registry.protocols.register_protocol_code` reads the pairing
+out of the registry owner's own namespace rather than off the class, and reads its
+absence as *declares no pairing* rather than as an error. What changes is which
 registry it resolves *to*: ``OSPF.__proto__`` is
 :attr:`ProtocolBase.__proto__ <pcapkit.protocols.protocol.ProtocolBase.__proto__>` rather
 than :attr:`Link.__proto__ <pcapkit.protocols.link.link.Link.__proto__>`, so OSPF does not

docs/source/contributing/conventions/registry-protocol.rst

@@ -74,7 +74,7 @@ generated registries spell by hand in ``_missing_``:
        if not (isinstance(value, int) and 0 <= value <= 0xFF):
            raise EnumValueError(f'{value!r} is not a valid {cls.__name__}')
 
-**Every registry overrides it**, so that ``register`` refuses what ``get`` refuses
+**Every registry has it overridden**, so that ``register`` refuses what ``get`` refuses
 (:issue:`1816`). Each vendor generator emits the override from the check it already
 writes at the top of ``_missing_``, with the same message. That is the ``FLAG`` of most
 crawlers, but a bespoke template's own range where its ``_missing_`` checks something

docs/source/engines.rst

@@ -188,7 +188,7 @@ preflight described at the top of this page.
 
    Only the engines above carry extra constraints. :mod:`pcapkit` itself and
    its ``default``, ``dpkt`` and ``scapy`` engines need nothing beyond their
-   ``pip install`` -- |dpkt|_ 1.9.8 and ``scapy`` 2.7.0 were both measured
+   ``pip install`` -- |dpkt|_ 1.9.8 and ``scapy`` 2.8.0 were both measured
    reading a capture on Python 3.14. The ``scapy`` engine needs **scapy 2.6.0 or
    newer**, which the ``Scapy`` extra requires: 2.5.0 can drop a PCAP-NG
    interface's timestamp resolution, reading nanoseconds as microseconds

docs/source/pcapkit/protocols/internet/ipv6_ext.rst

@@ -126,7 +126,7 @@ This class is reached in these ways:
 1. **An unrecognised protocol number.**
    :attr:`~pcapkit.const.ipv6.extension_header.ExtensionHeader.Shim6` is a real
    IANA extension header (:rfc:`5533`) with no dedicated parser, so
-   :meth:`Internet._lookup_next_layer <pcapkit.protocols.protocol.ProtocolBase._lookup_next_layer>`
+   :meth:`Internet._lookup_next_layer <pcapkit.protocols.protocol.Protocol._lookup_next_layer>`
    would default it to plain :class:`~pcapkit.protocols.misc.raw.Raw`. That
    has no ``next`` field, so the walk in
    :meth:`IPv6._decode_next_layer <pcapkit.protocols.internet.ipv6.IPv6._decode_next_layer>` would

pcapkit/protocols/internet/internet.py

@@ -182,7 +182,7 @@ def register(cls, code: 'Enum_TransType', protocol: 'ModuleDescriptor[ProtocolBa
         Arguments:
             code: protocol code as in :class:`~pcapkit.const.reg.transtype.TransType`
             protocol: module descriptor or a
-                :class:`~pcapkit.protocols.protocol.Protocol` subclass
+                :class:`~pcapkit.protocols.protocol.ProtocolBase` subclass
 
         Raises:
             pcapkit.utilities.exceptions.RegistryError: If ``protocol`` is not a

pcapkit/protocols/internet/ipv6_ext.py

@@ -93,7 +93,7 @@
 
 1. **An unrecognised protocol number.** :class:`~pcapkit.const.ipv6.extension_header.ExtensionHeader.Shim6`
    is a real IANA extension header (:rfc:`5533`) with no dedicated parser, so
-   :meth:`Internet._lookup_next_layer <pcapkit.protocols.protocol.ProtocolBase._lookup_next_layer>`
+   :meth:`Internet._lookup_next_layer <pcapkit.protocols.protocol.Protocol._lookup_next_layer>`
    would default it to plain :class:`~pcapkit.protocols.misc.raw.Raw`. That
    has no ``next`` field, so the walk in
    :meth:`IPv6._decode_next_layer <pcapkit.protocols.internet.ipv6.IPv6._decode_next_layer>`

pcapkit/protocols/link/link.py

@@ -138,7 +138,7 @@ def register(cls, code: 'Enum_EtherType', protocol: 'ModuleDescriptor[ProtocolBa
         Arguments:
             code: protocol code as in :class:`~pcapkit.const.reg.ethertype.EtherType`
             protocol: module descriptor or a
-                :class:`~pcapkit.protocols.protocol.Protocol` subclass
+                :class:`~pcapkit.protocols.protocol.ProtocolBase` subclass
 
         Raises:
             pcapkit.utilities.exceptions.RegistryError: If ``protocol`` is not a
@@ -158,7 +158,7 @@ def register(cls, code: 'Enum_EtherType', protocol: 'ModuleDescriptor[ProtocolBa
 
            Takes the protocol as one ``protocol`` argument, a
            :class:`~pcapkit.corekit.module.ModuleDescriptor` or a
-           :class:`~pcapkit.protocols.protocol.Protocol` subclass, in place of
+           :class:`~pcapkit.protocols.protocol.ProtocolBase` subclass, in place of
            the ``module`` and ``class_`` names.
 
         """

pcapkit/protocols/protocol.py

@@ -1011,7 +1011,7 @@ def analyze(cls, proto: 'int', payload: 'bytes', **kwargs: 'Any') -> 'ProtocolBa
             **kwargs: Arbitrary keyword arguments.
 
         Returns:
-            Parsed payload as a :class:`~pcapkit.protocols.protocol.Protocol`
+            Parsed payload as a :class:`~pcapkit.protocols.protocol.ProtocolBase`
             instance.
 
         """
@@ -1044,7 +1044,7 @@ def register(cls, code: 'int', protocol: 'ModuleDescriptor | Type[ProtocolBase]'
         Arguments:
             code: protocol code
             protocol: module descriptor or a
-                :class:`~pcapkit.protocols.protocol.Protocol` subclass
+                :class:`~pcapkit.protocols.protocol.ProtocolBase` subclass
 
         Raises:
             pcapkit.utilities.exceptions.RegistryError: If ``protocol`` is not a