docs(contributing): sweep the conventions pages for accuracy and concision (#719)

[JarryShaw]

Please follow the guide below

• Searched for similar pull requests
• Followed the coding style (make pylint, make mypy, make isort) — N/A, .rst only
• make test passes, and a test case covers the change — the eight suites reading these pages: 111 passed, 1 skipped, 241 subtests
• Added a changelog entry under docs/source/changelog/ and regenerated CHANGELOG.md, if the change is user-visible — N/A — centralised in docs(changelog): shared 1.5.0 changelog — long-lived, merges last (#610, #616, #617, #618, #620) #657

What is the purpose of your pull request?

• docs — documentation only

---

Description of your pull request and other information

The docs/source/contributing/conventions/ slice of #719. Factual corrections, each re-derived against the tree:

Was	Now	Verified against
EtherType's company names / Socket's Registered by Xerox mint	both unmint; CGAType is the only minting _missing_, so the criterion decides the name	pcapkit/const/reg/ethertype.py:540, pcapkit/const/ipx/socket.py:83, pcapkit/const/mh/cga_type.py:54, pcapkit/vendor/ipx/socket.py:253-261, pcapkit/corekit/enum.py:249-254
the ast snippet (ast.Name only)	matches attributes too — it printed 1 MINT / 0 UNMINT, now 1 / 114	run both ways
"Every registry defines _missing_"	121 of 127, six named	AST walk of pcapkit/const/**
"a handful" of bespoke __new__, "tracked in #860"	six named classes, all on the base; #860 closed	pcapkit/const/ftp/command.py:266 et al.
the 6 mh/ngap helpers' "values are numeric codes"	five are; PDUKind's are str — and it was in two table rows	pcapkit/protocols/application/ngap.py
TCP/UDP/SCTP/DCCP "values are service names"	the member name is; the value is 'tcpmux [1 - tcp]'	pcapkit/const/reg/apptype/tcp.py
"9 module-level sections ... one per top-level module"	8 of the 9 name a module; pcapkit.interface has none	docs/source/changelog/1.5.0.rst
NO_DEFAULT and ABSENT lack __copy__/__deepcopy__/__reduce__	NO_VALUE does too, and the consequences differ	pcapkit/corekit/sentinels.py:158,162,173
AbsentType docstring quoted as saying it is private	it does, in a later paragraph — the quoted excerpt did not; quote dropped	pcapkit/corekit/sentinels.py:439-466
/issues/847, /issues/913	/pull/ — both are pull requests	issueOrPullRequest

Concision: dropped timed context (the page's former title, #877 phase 2's two-pass history, the pre-#937 casing narrative, the pre-restructure changelog shape), fixed has its own status of its own, softened two unquantified "most" claims, and added two Mermaid flows — _missing_'s outcomes and get's dispatch — modelled on contributing/workflows.rst:102.

Net +21 lines, so this slice did not get shorter: 22 of those are the two Mermaid blocks and mint-criterion.rst grew 30, the corrected worked examples needing more words than the wrong ones did (sentinel-convention.rst −16, process.rst −5, index.rst −3). docutils reports the same two INFO diagnostics as the base and no new ones.

[JarryShaw]

NEEDS CHANGES at 06b8eac27 — sonnet cross-review, round 1. One real
arithmetic defect, now fixed at e595d26cf.

registry-protocol.rst:466-467 tallied the CommandType column as s 26,
a 18, s/p 3, blank 1 — 48 of 64 rows, omitting p 16 entirely, while the
ConformanceRequirement half of the same sentence (o 28, m 27, h 7,
m [1] 2) correctly sums to 64. Two halves of one parenthetical, tallied to
different completeness.

I re-derived it against the live registry rather than taking the review's word:

$ curl -sS .../ftp-commands-extensions-2.csv   # 64 data rows
'type': {'s': 26, 'a': 18, 'p': 16, 's/p': 3, '': 1}  sum=64
'conf': {'o': 28, 'm': 27, 'h': 7, 'm [1]': 2}        sum=64

Not a scoping choice: CommandType.P is a real member and
pcapkit/vendor/ftp/command.py:26-29 maps 'p' to it. Added p 16 and a closing
sentence saying both tallies cover all 64 rows, so the next reader can check the
sum without refetching.

tests.project.test_conventions_doc_claims → Ran 38 tests ... OK (skipped=1).

The review separately confirmed, against live sources, TransportProtocol's
14,536-row census and FEATCode's 11/10 + 52/5 + 1 split — both exact — and that
#275's bug→invalid swap really is the same second (2026-09-23T22:01:30Z).
Those were three of the five claims #968's author could not settle.

[JarryShaw]

GOOD TO GO at e595d26cf — sonnet cross-review, round 2 clean.

The CommandType fix is confirmed complete, not just present: one hunk,
2 insertions/1 deletion, nothing else touched; grep -rn '\b48\b' over the
conventions pages returns nothing, and the file's two other mentions of
CommandType/ConformanceRequirement (:462, :519) cite no row count, so no
dependent sentence went stale behind the number.

Round 2 also closed the sub-claim round 1 had time-boxed out. Running the page's
own AST-walk algorithm verbatim over pcapkit/const/** reconciles the population
exactly: 1 mint (CGAType) + 114 unmint + 6 neither = 121, the six being the
five flag registries (BindingACKFlag, BindingUpdateFlag, HandoverACKFlag,
HandoverInitiateFlag, tcp.Flags) plus hip.transport.Transport. Three bodies
read directly — each only range-checks and defers to super()._missing_, as the
page says. ftp.command.CommandType is a seventh such _missing_ but is
EnumLookup, IntFlag, not an EnumRegistry subclass, so it is correctly outside
the 127.

Residuals it names rather than papers over: three of the six flag bodies were
classified by AST but not read verbatim; the universal-quantifier sweep and the
quotation sweep of process.rst, index.rst and
extension-header-subclassing.rst are partial. Nothing found contradicts the
text.