docs: render #771's two unregistered-member helpers in numbers.rst (#780)

[JarryShaw]

Please follow the guide below

• You will be asked some questions, please read them carefully and answer honestly

• Put an x into all the boxes [ ] relevant to your pull request (like that [x])

• Use Preview tab to see how your pull request will actually look like

• Searched for similar pull requests

• Followed the coding style (make pylint, make mypy, make isort)

• make test passes, and a test case covers the change

• Added a changelog entry under docs/source/changelog/ and regenerated CHANGELOG.md, if the change is user-visible — N/A — changelog 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?

Tick the commit type your subject line carries.

• 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

Closes #780.

#771 added _rebuild_unregistered_member and _reduce_unregistered_member to pcapkit/corekit/fields/numbers.py. Both carry full Args:/Returns: docstrings, but numbers.rst listed no stubs for them, so neither was rendered.

• Stubs — two .. autofunction:: entries under the existing Internal Definitions heading, after the NumberField autoclass (source order). Individual stubs follow the _purge precedent at docs/source/pcapkit/foundation/engines/3rdparty.rst:481; :private-members: stays commented out repo-wide.
• Prose → :func: — the only two convertible references are both to _rebuild_unregistered_member, at numbers.py:680 (in EnumField._unregistered_member's Note:) and numbers.py:804 (in _reduce_unregistered_member's Returns:). Relative roles, matching _pcap_backend.py:198's ``:func:_purge```. Everything else still in double backticks is an enum/object internal with no stub here (reduce_ex`, `value`, `name`, `new`, `value2member_map`, `missing` — the last is in `conf.py`'s `exclude-members`).

Verification — full sphinx-build -b html -E, Sphinx 9.1.0 / Python 3.14.7, with the resolved package root asserted in-process as this tree (the venv's editable install otherwise wins over cwd). 53 warnings before, 53 after — byte-for-byte identical after sorting, so no new warning and no duplicate object description for either stub. Both stubs render their own id= anchor and Args:/Returns: body; the two prose references resolve to internal links (xref py py-func), with zero plain literals left for that name.

[JarryShaw]

Cross-review at e6a50a75c (sonnet, a different model from the author): GOOD TO GO, no required changes.

The claim I could not check cheaply is confirmed, and confirmed the hard way. Both trees built separately with PYTHONPATH forced to each and pcapkit.__file__ printed in-process before the build — /tmp/pr781-main/pcapkit/__init__.py against the head's own worktree, so neither read the shared checkout. sphinx-build -b html -E, Sphinx 9.1.0 / Python 3.14.7: 53 warnings each, and after stripping the two builds' distinct absolute-path prefixes and sorting, diff was empty with matching md5 (67de2ab6…). The three duplicate object description warnings are present identically in both.

The mechanism claim behind that measurement also holds, which matters because it decides whether the warning diff means anything: sys.meta_path in the venv is [DistutilsMetaFinder, BuiltinImporter, FrozenImporter, PathFinder, _EditableFinder] — the editable finder really does sit after PathFinder, so PYTHONPATH wins. Demonstrated both ways: without it, import pcapkit resolves to the shared checkout; with it, to the worktree.

Both stubs render. Own id= anchors, full Args:/Returns:/Return type: bodies, and both :func: roles resolve to internal links — <a class="reference internal"> wrapping <code class="xref py py-func">, with the auto-appended () that only a resolved func-xref gets. The baseline has zero stub anchors and exactly one plain literal with no link, matching the author's "1 literal / 0 links". The relative-role concern I raised is refuted: both resolve, including the one from a method docstring at :680, which was the case I thought might fail silently.

One claim narrower than it reads, not a defect. The author justified placement as "the file follows source order". numbers.rst is actually ordered thematically — Sized, Enumeration, Internal — and NumberField is numbers.py's first class at :35 yet is documented last. The narrow claim does hold: the helpers at :757 and :785 come after :35, and the Sized Fields section is internally source-ordered. Worth knowing the file's real convention.

Also swept: no stub exists anywhere under docs/source/ for any of the twelve names left in double backticks, so none was a missed conversion, and _missing_ is confirmed in conf.py:115's exclude-members where a role could never have resolved. Template intact, one commit, Closes #780.

Eight CI legs still outstanding on this head (19 success, 3 expected skips, 0 failures). This is a review verdict, not a merge signal.