fix(packaging): ship vdsim_preset.py in the wheel - #7

Rebased onto main (bcad3db). One source line in the wheel manifest, plus a test that
pins the class of defect it belongs to.

(i) What was missing

python/vdsim_preset.py. The if(DEFINED SKBUILD) install list in
python/CMakeLists.txt shipped vdsim_render.py but not the module it imports, so in
any clean environment installed from a wheel:

>>> import vdsim_render
ModuleNotFoundError: No module named 'vdsim_preset'

Measured 2026-09-18 in two clean environments (docker python:3.11-slim, Windows
CPython 3.12 venv) against artifact set from wheels run 35309944365. vdsim_preset.py
entered the tree with the render-preset work (PR #4) and was never added to the install
list; the conflict in this rebase is the same list gaining vdsim_render3d.py from
PR #6, resolved as a union of both entries.

(ii) Why Q14 verify did not catch it

Two independent blind spots, both of which only see what they are told to look at:

• CIBW_TEST_COMMAND (.github/workflows/wheels.yml:28) imports vdsim and
  constructs Sim twice. It never imports vdsim_render, so the broken import is
  never executed.
• tools/verify_wheel_packaging.py inspects the wheel's zip member list against a
  hand-written set (vdsim_lab.py, vdsim_plant.py, catalog/, quickstart.py,
  configs, .tir policy). vdsim_render.py and vdsim_preset.py are not in that set,
  so a wheel missing either one passes.

Neither gate is a closure check, so a module can be shipped while its dependency is not.
The source tree never shows it: in-tree, python/ is on sys.path and both files are
present. This is why the whole matrix (6 wheels x verify) was green on a broken wheel.

(iii) What the new test does and does not guarantee

tests/scripts/test_render_presets.py::test_wheel_ships_every_first_party_import

Guarantees:

• The install list is parsed from python/CMakeLists.txt itself, not restated, so the
  check follows the list when it changes.
• For every shipped .py, every top-level import that resolves to a file in
  python/, cosim/ or examples/ is itself in the install list. That closes the
  "ship A, drop A's dependency" class of defect at its source.

Does not guarantee:

• That the built wheel actually contains those files. This is a static read of the
  CMake install rules, not of a .whl. A scikit-build-core/CMake regression that drops
  a listed file would still pass.
• Anything about package_data, config trees, or the catalog/ package directory —
  only top-level .py modules named in the install list.
• Runtime importability under a different interpreter or platform.

The wheel-side counterpart (import every listed module from the installed wheel in
CIBW_TEST_COMMAND) is Q19-b and is deliberately not in this PR: it changes
.github/workflows/wheels.yml, not the registration surface, and is verified by a
workflow_dispatch run rather than by ctest.

Registration surface / currency

python/CMakeLists.txt is on the registration surface, so the currency gate fails until
docs/VALIDATION.md is re-promoted against this tree. Test count is expected to stay
492/492 (this PR adds a check inside an existing ctest target, not a new target).
Promotion follows three consecutive same-commit green CI runs, per the standing
contract.

Update (13e28de): the first CI run (35349441450) confirmed the predicted gate
failure -- registration surface changed between the recorded commit 1fc790e and the built commit ...: python/CMakeLists.txt -- with ctest itself reporting 492/492 in the
same job. The currency block is now parked at PENDING with the reason recorded
(commit 13e28de), and is re-promoted on this branch after three consecutive green
canonical runs on the same commit.