docs(contributing): cite the issue, not the pull request, on the conventions pages (#719)

[JarryShaw]

Please follow the guide below

• Searched for similar pull requests
• Followed the coding style (make pylint, make mypy, make isort) — prose only, no Python touched
• make test passes, and a test case covers the change — tests/project/test_conventions_doc_claims.py already asserts on these pages
• 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?

• fix — corrects a defect
• feat — adds a feature
• perf — changes performance, not behaviour
• refactor — changes neither behaviour nor performance
• test — tests only
• docs — documentation only
• ci — workflows or build tooling
• chore — anything else

---

Description of your pull request and other information

Implements the #719 ruling under docs/source/: a pull request describes a point in time, so cite
the issue the work belonged to, or describe the change with no number at all.

Counts, derived against this base. 582 #NNN references under docs/source/ — 220 pull
requests, 358 issues, and 4 occurrences naming a GitHub discussion (#106, #251), which is neither.
188 of the 220 sit in changelog/ and 1 more in changelog.rst, both exempt, leaving 31 acted
on: process.rst 22, registry-protocol.rst 5, extension-header-subclassing.rst 2,
mint-criterion.rst 2. That bucket is now at zero pull-request references; its issue references rose
72 → 87.

Changed. process.rst — breaking's worked examples now cite #805, #759, #618, #806 and #778;
the label census and the shared-changelog mentions are described rather than numbered, and the
commit-count command looks its pull request up by title. registry-protocol.rst — #903, #808, #877;
the two mh.py overrides' widening and their later deletion were each ruled in a review thread
rather than on an issue, so both read as prose. extension-header-subclassing.rst — #917, the rename
the second-base ruling was given in review of, since no issue owns that ruling alone.
mint-criterion.rst — #841 ×2.

Verified. 37 passed, 1 pre-existing skip. Sphinx against a main baseline: 63 warning lines
each, 0 new, 0 gone, 7 duplicate-label and 0 orphan both sides, each build's pcapkit.__file__
printed to prove its tree. All 45 link targets are issues and every displayed #NNN matches its own
URL. Over-88 lines under docs/source/contributing/ went 23 → 22, none added.

[JarryShaw]

GOOD TO GO at df61fce5e — sonnet cross-review, round 2. Labelled review: good-to-go.

The deletion sentence is now true and its referent resolves locally. Issue #935's thread holds
only the widening ruling; the deletion was decided in #940's own review thread, where the question
("why must we have the two overrides tho?") and the answer both sit. So "given in review of the
widening itself" is literally accurate. And "the widening itself" nominalizes "widened" nine words
earlier in the same table cell — a local antecedent, where the old "that same widening" had no
widen-rooted word anywhere in that cell.

It caught a trap in my own brief, and it would have cost a false accusation. I told it to read
git diff b4823c4d1 df61fce5e. That diff is contaminated — the branch was rebased between rounds onto
a main that had merged a sibling change, so it reads:

naive b4823c4d1..df61fce5e        4 files, +312/-8   <- includes a 297-line page this author never wrote
against the real parent           4 files,  +76/-60  <- the actual change
tests/project/... vs real parent  empty              <- 100% rebase drift

I already knew the main-moved-under-a-branch form of this; the rebase-between-review-rounds form is
new to me. Even an explicit old-head-to-new-head pair mixes in everything the new base absorbed.
Compare against the PR's actual parent, or restrict to paths the intervening merge did not touch — which
is what it did, two ways, before concluding.

Re-derived independently: all 28 distinct #NNN across the four files classify as issues, zero
pull requests, zero discussion-candidates; link count 45 under the test's own _every_page() scope
with 0 pull-targeted and 0 displayed-versus-URL mismatches, and it explained the gap against its first
narrower count of 43 rather than leaving it hanging; over-88 lines 23 → 22 measured against current
main, with one line genuinely dropped and one merely shifted, so "none added" holds;
37 passed, 1 skipped, 140 subtests. Orphan sweep over all four files: 8 hits, every one read in
context, no orphans.

Both the commit message and the PR body were corrected to match the narrowed diff — three citations
re-pointed rather than five, with the two pull-request-sourced ones carved out as prose.

UNVERIFIED by it: the Sphinx warning-set rebuild, skipped within budget.

Unpublished and awaiting you — I do not merge.