The version in pyproject.toml was static, while releases are derived from
conventional commits and tagged by CI. The first release after packaging was
cut as v0.4.0 while the file still declared 0.3.0, so the Python package and
the Nix store path both understated the release.
The version cannot be set by hand in the pull request that causes a release:
it is computed from the commit messages and is only known inside the release
job. So the release job now writes it into pyproject.toml, commits it as
chore(release), and tags that commit.
Neither push re-triggers the workflow -- it listens on main only for the
image-affecting paths, and pyproject.toml is not one of them -- and the
chore(release) subject produces no bump of its own on the next run. The branch
push is ordered before the tag push so a rejected push cannot leave a tag
pointing at a commit that is not on main.
pyproject.toml is bumped to 0.4.0 here to correct the current state; from the
next release onward CI maintains it.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
