docs(corekit): convert bare citations to the issue role in corekit docstrings

[JarryShaw]

Description

Applies the citation roles added in #998 across pcapkit/corekit/ — 100 roles in 8 modules, all
inside docstrings and #: attribute doc comments, the two places autodoc parses as reStructuredText.
Measured base → head by tokenising both commits: 99 bare #NNN citations converted, plus one
explicit hyperlink in enum.py (#930 written out as a full URL) that became :issue:930``.
Rendered text is unchanged in both cases, since the caption is #%s. Held until #998 landed, because a converted docstring built against a tree without
the roles errors on an unknown role.

Plain # comments keep the bare #NNN form, per the ruling on #989: GitHub's code-tree view links
them, and a role there would render as neither a link on GitHub nor a reference in Sphinx. 11 such
citations in these files are deliberately untouched.

Verification

• sphinx -b html exit 0, 0 unknown interpreted text role errors, 61 warnings / 2 errors —
  unchanged from the pre-existing baseline.
• tests/corekit — 400 passed, 16 skipped, 658 subtests, 0 failed.
• Cross-reviewed on a different model, which independently reproduced the build counts in separate
  worktrees and confirmed no plain comment was converted and no #: comment or docstring was missed.

Checklist

• Commit type is in the subject line
• Tests pass locally
• Changelog entry — N/A, centralised in docs(changelog): shared 1.5.0 changelog — long-lived, merges last (#610, #616, #617, #618, #620) #657

[JarryShaw]

GOOD TO GO at a75a8c932 — sonnet cross-review, a different model from the one that produced the
tranche, briefed to falsify. It attacked six load-bearing claims and confirmed all six. I re-derived
the one it corrected before posting this.

Correction to the description above, which the review caught and I verified by tokenising both
commits: the 100 roles are 99 bare #NNN citations plus one explicit hyperlink. enum.py carried
`#930 <…/issues/930>`__ written out in full, and that became :issue:930``. Measured base →
head: bare citations 99 → 0, hyperlinks 1 → 0, roles 0 → 100. Rendered text is unchanged either way,
since both captions are #%s.

Per-claim, with the measurement it made itself:

• Plain comments untouched — the plain-# token lists are byte-identical between base and head
  in all 8 files; 0 roles in plain comments, 11 bare citations still there. My own tokenise agrees:
  bare_plain is 11 before and 11 after.
• No misses — 0 bare citations remain in any #: comment or docstring in the 8 files. The 11 are
  all plain comments: field.py 7 (line 546 carries two), misc.py 2, numbers.py 1,
  infoclass.py 1. collections.py and module.py also hold bare citations, all plain, correctly
  left alone.
• Build counts — it built both revisions in separate worktrees and got 61 warnings / 2 errors
  on each, with identical warning sets after normalising line numbers, and 0 unknown-role errors.
• Rendering — no inline literal was converted; the visible text of all 24 built corekit API
  pages is identical, with enum.html going from 0 to 50 issue links.
• Prose — after normalising roles, the token stream of every file is unchanged, every inline
  literal's content is preserved, no literal was newly split across lines, and all 8 files parse.

One honest limit it reported rather than papering over: it did not re-check carried-over phrases such
as the attribution on #575 and #911 against their threads. That would not change this verdict, since
the diff only moves that prose, but it is not evidence those phrases are right.

CI at a75a8c932: 27 green, 3 skipped, 0 failed, 41 still running. Not ready to merge until
those finish — I will say so when they do.

[JarryShaw]

CI note: Required checks passed went red on attempt 1, and it is not this diff. Run
37092125968: 61 of 62 jobs succeeded, Python 3.12 (unit) came back cancelled, and the gate
job then failed for exactly the reason it exists — it treats a cancelled dependency as not-a-pass.
Its log shows test: cancelled against integration: success, engine-tests: success,
pypcap-parity: success.

No test failed anywhere. The cancelled job completed steps 1-5 green and died inside Run unit tests,
so the step never finalised and its log blob is gone (the API returns BlobNotFound) — there is no
failure output because there was no failure, only a kill.

What makes it a runner anomaly rather than a 3.12 problem: on the same commit, Integration Python 3.12 and all six Engines Python 3.12 legs passed, and the four sibling unit legs took 13-17 minutes
each — 3.10 started at the same second and finished in 13m31s. The 3.12 leg ran 55 minutes, past the
timeout-minutes: 45 set at .github/workflows/unit-tests.yml:53. I am not going to assert the exact
mechanism of the kill, since nothing I can read from here records it.

Re-ran the failed jobs only; attempt 2 is in flight. The review: good-to-go label stands because the
verdict tracks the head sha, not the CI run, but this is not ready to merge until the gate is green.

[JarryShaw]

Ready to merge at a75a8c932 — closing the "not yet" on the CI note above. The rerun of attempt 1's
cancelled leg came back green: Python 3.12 succeeded in 16m52s (04:05:59Z → 04:22:51Z), which is
squarely in the 13-17 minute band its siblings took, and Required checks passed went to success four
seconds later.

Current state at this head: mergeStateStatus CLEAN, rollup SUCCESS, 69 ok / 3 skipped / 0
failed / 0 in flight. All six required contexts are accounted for — Required checks passed success
and Compat Python 3.10-3.14 success, with Compat Python 3.15 (scheduled) skipped as it always is.

That 16m52s is the useful evidence for the earlier diagnosis: the same commit, the same step, the same
runner image, finishing in a normal time. The 55-minute attempt-1 run was the anomaly, not the diff.

Cross-review verdict GOOD TO GO stands at this head, and nothing has been pushed since — so the
review: good-to-go label still tracks a75a8c932. Unpublished work, nothing merged by me: this is
yours to merge.