ci(publish): fail fast on tag/version mismatch (fix v0.0.4 PyPI release)

[Halvani]

Problem

The v0.0.4 release failed to publish to PyPI. The release tag v.0.0.4 was cut at commit d81e248, where pyproject.toml still read version = "0.0.3" — the actual version bump to 0.0.4 landed in a later commit (a407185). The publish workflow checked out the tag, built posnoise-0.0.3, and PyPI rejected it with "file already exists" (0.0.3 was already published).

Verified locally by building the package at the tag:

tag	version in pyproject.toml at tag	built artifact
v.0.0.1	0.0.1	posnoise-0.0.1 ✓
v.0.0.2	0.0.2	posnoise-0.0.2 ✓
v.0.0.3	0.0.3	posnoise-0.0.3 ✓
v.0.0.4	0.0.3	posnoise-0.0.3 ✗ (duplicate)

The first three tags are all correctly aligned; only v.0.0.4 is broken. (Also confirmed the pattern-list .txt data files ARE correctly bundled in the wheel — packaging/data files are not the issue.)

Fix

Add a pre-build step to .github/workflows/python-publish.yml that compares the release tag against the version declared in pyproject.toml and fails fast with a clear message when they do not match — instead of building a duplicate and getting a confusing downstream PyPI 400.

⚠️ This PR alone does not publish v0.0.4

A PR cannot move a remote git tag, so the broken v.0.0.4 tag still needs to be corrected separately (by the maintainer) before re-publishing:

# delete the misaligned tag locally and remotely
git tag -d v.0.0.4
git push origin :refs/tags/v.0.0.4
# recreate the tag at the commit where version IS 0.0.4
git tag v.0.0.4 <commit-where-pyproject-is-0.0.4>
git push origin v.0.0.4

Then delete the failed GitHub release and create a new release from the corrected tag — this re-triggers the publish workflow. With this PR merged, the new workflow step will confirm alignment before building.