ci: verify the wheel installs before publishing it

[melbinjp]

release.yml built a wheel, ran twine check on it, and uploaded it to PyPI
without ever installing it.

The job that does install a wheel and import every module out of it already
existed, in scheduled-ci.yml, and it is good. It just had one caller and the
wrong one. The weekly run asks "did the world break rigout since our last
commit?" - a real question, and the reason it was written. Nobody was asking
"is the wheel we are about to publish installable?", and that is the question
where a wrong answer is permanent: PyPI does not allow a version to be
re-uploaded, so a broken 0.3.2 can only be answered by shipping 0.3.3 to
everyone who installed in between.

The bug class is invisible to everything else on the release path. pip install -e . imports out of src/, so it cannot see a module missing from the wheel, a
mis-declared package, dropped package data, or a console script pointing at a
function that does not exist. twine check reads metadata and never installs
anything. Both are green on a wheel that fails for every user.

This is not hypothetical here. PR #21's own description records that "a clean
installed-wheel test also exposed a Windows venv redirector PID mismatch in
detached startup" - that test has already caught a real bug in this project, and
it was never on the path where it mattered most.

What changed

• verify-wheel.yml (new, reusable) holds the job, with an optional artifact
  input. Empty means build from the checkout, the existing behaviour. Set means
  download and verify that artifact instead.
• release.yml calls it between build-release and publish-pypi, passing
  release-dist, so what gets installed is the exact file that will be
  published rather than a rebuild that might differ.
• scheduled-ci.yml calls it with no input. The four shared steps are
  byte-identical to what it ran before.

Two things found while doing it

The version check could not have run on the release path. main recently
fixed the tomllib/tomli fallback for Python 3.10, but installed tomli in
the build step. The build step is skipped when an artifact is passed, so
leaving it there would have failed every release-time run on 3.10 with the same
ModuleNotFoundError that fix was for. The install moved to the step that reads
pyproject.toml.

Declaring actions: read in the reusable workflow breaks the weekly run. A
called workflow may not request more permissions than its caller grants, and
scheduled-ci.yml caps its run at contents: read. The first attempt failed at
startup for exactly this reason. That would not have broken the release it was
written for - it would have broken the Monday run, at startup, in the workflow
whose entire purpose is noticing breakage nobody is watching for. So
verify-wheel.yml now declares no permissions and inherits from its caller, and
release.yml grants actions: read on the calling job.

Verification

Both paths were run on a temporary workflow on this branch, since the release
path is otherwise only reachable by pushing a tag, which publishes for real.
That workflow has been removed; pyproject.toml is identical to main.

Green, 13/13, with the conditional branching correctly in all twelve matrix
jobs - build=skipped download=success on the artifact path,
build=success download=skipped on the checkout path, across
ubuntu/macos/windows and Python 3.10/3.14.

Then the gate was checked in the other direction, because one that only ever
says yes is not a gate. A console script pointing at a function that does not
exist was added to pyproject.toml. pip install -e . accepted it without
complaint, which is the blind spot. All twelve jobs then failed with:

BROKEN entry point: rigout-broken = rigout.server:function_that_does_not_exist
-> AttributeError: module 'rigout.server' has no attribute 'function_that_does_not_exist'

Unrelated, found while checking dates

CHANGELOG.md dates 0.3.1 as 2026-08-02. PyPI says it was uploaded
2026-08-17. 0.3.0's date is correct. Left alone here rather than mixed into a CI
change.

[github-actions]

Jules Review

COVERAGE: 77e51a3 3 files

Summary

This PR extracts the wheel verification logic into a reusable workflow (verify-wheel.yml) and inserts it into the release path (release.yml) right before publication to PyPI, closing a critical gap where a broken wheel could be published. It correctly tests the exact artifact that will be uploaded. The changes handle the tomli fallback properly across both artifact and checkout modes and thoughtfully manage GitHub Actions permissions to prevent breaking the scheduled CI run.

VERDICT: approve

---

This review never edits code or force-blocks a merge. No blocking issues were found, so this PR was auto-approved.

[github-actions]

Automated approval: Jules found no blocking issues (verdict: approve). See the review comment above.