Vendor Python 3.10 intersphinx inventory for pydabs docs - #6897

Problem

The pydabs docs build (python/Taskfile.yml pydabs-docs) resolves stdlib cross-references via Sphinx intersphinx, which fetched https://docs.python.org/3.10/objects.inv over the network on every build. When docs.python.org returns 503 (as it did this morning — see internal report), the inventory fails to load, the stdlib references (collections.abc.Callable, types.ModuleType) go unresolved, and --nitpicky + -W turn those warnings into a hard build failure.

Note the 503 trips -W on its own even without --nitpicky: intersphinx logs its own "failed to reach any of the inventories" warning independent of nitpick mode, so fixing the gate flags wouldn't address the root cause — the build's network dependency on docs.python.org.

Fix

Vendor the inventory locally (python/docs/_inventory/python-3.10.inv) and point intersphinx at the committed file:

intersphinx_mapping = {
    "python": ("https://docs.python.org/3.10", "_inventory/python-3.10.inv"),
}

The public URL is still used to build the output links; only the inventory is read from disk, so a docs.python.org outage can no longer break the build. Python 3.10 is frozen, so the file never needs refreshing. This keeps the strict -W gate and the stdlib hyperlinks intact while removing the flaky network dependency.

Verification

• sphinx-build docs docs/_output --nitpicky --fresh-env --keep-going -W succeeds with zero warnings.
• intersphinx logs loading intersphinx inventory 'python' from _inventory/python-3.10.inv (local, not network).
• Build still succeeds with outbound HTTPS blocked, proving it no longer depends on docs.python.org.

This pull request and its description were written by Isaac.