fix: stop the release from trying to publish its dependencies - #539

Every release since v2.11.0 has failed, ten in a row, ending with:

    403 Invalid API Token: project-scoped token is not valid for
    project: 'PyYAML'

The build runs `pip wheel -w dist .`, which resolves and writes a wheel
for the project *and every dependency*, so dist/ holds commit_check and
pyyaml. Reproduced locally:

    $ pip wheel -w dist .
    commit_check-2.13.4-py3-none-any.whl
    pyyaml-6.0.3-cp311-...-manylinux_2_28_x86_64.whl

That was harmless while the upload named what it wanted. #453 migrated
from twine to pypa/gh-action-pypi-publish and the scoping was lost in the
move:

    -  run: twine upload dist/commit_check*
    +  uses: pypa/gh-action-pypi-publish@...

The action has no file selection -- it uploads the whole directory -- so
PyPI is asked to accept PyYAML under a token scoped to commit-check, and
correctly refuses.

Nobody noticed because the release still works. Uploads happen per file
and commit_check sorts before pyyaml, so our wheel lands, then the job
goes red on someone else's. The package is on PyPI; only the workflow
looked broken, which is a state that is easy to keep ignoring.

`--no-deps` builds our wheel alone, which is all this workflow ever meant
to publish:

    $ pip wheel --no-deps -w dist .
    commit_check-2.13.4-py3-none-any.whl

Also adds a guard after the build. The publish step cannot select files,
so "dist/ contains only our artifacts" is a precondition it depends on and
cannot verify; the guard checks it where the problem is fixable and names
it, instead of surfacing as a 403 about a project we do not own. Checked
against both states: it fails on the old dist/ and passes on the new one.

Note for later, not changed here: this workflow has only ever published
wheels -- `pip wheel` produces no sdist, and PyPI has none for any
version. Switching the build to `python -m build` would add one, but that
changes what a release contains and belongs in its own change.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01U9zFxq8V4qxG4aMzJhGBFn

Review pointed out the guard tested only the prefix, so anything called
commit_check-* passed it -- an sdist, a stray .txt, a leftover directory.
Confirmed against a dist/ holding all four shapes: the old expression
flagged just pyyaml and waved the other three through.

The tighter form says what the step actually depends on. dist/ should
hold our wheels and nothing else, so a release that starts producing
something else should stop and be looked at, rather than be uploaded
because it happened to carry the right prefix.

That includes an sdist, deliberately. Adding one is a change to what a
release contains, and it should be made on purpose -- the guard failing
with the file named is the prompt to update this line, not an obstacle
to route around.

Error message now says "wheels" rather than "artifacts", matching what
is being checked.

Verified by extracting the guard from the workflow YAML and running it
verbatim against the two real dist/ directories from the earlier
reproduction: exit 1 naming pyyaml on the pre-fix build, exit 0 on the
--no-deps build.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01U9zFxq8V4qxG4aMzJhGBFn