docs: roles naming aenum, pcapfile, pyshark and pcap still render as unresolved chips outside conventions.rst #1920

#934 part C settled this: a package whose objects.inv holds no py: objects cannot be cross-referenced, and its roles become literals. The owner agreed those packages cannot be cross-referenced. docs/source/conf.py:169-180 states the same policy. AenumRoleExclusionTests (tests/project/test_conventions_doc_claims.py:696) enforces it for conventions.rst only.

On 95caa8b36, roles naming those packages remain elsewhere:

• format_aenum_class (conf.py:589-622), added for docs: aenum and stdlib enum unions render as IntEnum | IntEnum and Enum | Enum #1858, emits a :py:class: role for every aenum class. That fills the const, corekit and protocol pages with unresolved aenum.IntEnum, aenum.StrEnum and aenum.IntFlag chips.
• engines/3rdparty.rst and toolkit/3rdparty.rst use :mod:pcap``, pcapfile.* and `pyshark.*` roles.
• corekit/fields/numbers.py uses aenum.extend_enum.

Fix: have the formatter return a qualified literal, which keeps #1858's disambiguation; demote the hand-written roles; and widen the guard test to docs/ and pcapkit/. If the formatter's role was a deliberate exception, the scope narrows to the hand-written roles.

Found in the #1103 round-4 sweep.