`phys.cpp` still uses raw CPython C API + setuptools.Extension, not nanobind

[petercorke]

Unlike RTB's fknm/frne and spatialgeometry's scene.cpp, phys.cpp
(the step_v/step_shape physics extension) was never ported to
nanobind + scikit-build-core/CMake -- it's still built via
setuptools.Extension in setup.py, with PyArg_ParseTuple/
PyMethodDef/PyModuleDef raw CPython API calls.

Discussed 2026-07-26: this is lower priority than the other two ports
were, because the reasons they needed it don't really apply here --
phys.cpp is just two stateless numerical functions operating
in-place on numpy array data (PyArray_DATA), with no persistent C++
objects or ownership to get wrong, and minimal boilerplate already.
It also already has a working pure-Python fallback
(_step_v_py/_step_shape_py in Swift.py, same facade pattern as
RTB's fknm), so it already degrades gracefully without the compiled
extension -- including, presumably, under Pyodide/JupyterLite, without
needing a WASM-compatible build of phys.cpp at all.

Proposed fix (low priority): port to nanobind + scikit-build-core
for build-tooling consistency with fknm/frne/scene_nb across the
three repos -- not because it fixes a real bug, just uniformity. Not
worth doing unless/until the other, actually-motivated tech-debt items
are cleared first.