Build a wheel in the release workflow

[Hansheng-Li]

tasktiger publishes an sdist and nothing else — PyPI has a single file for 0.25.0, and only 0.9.5 and 0.10.1 have ever shipped a wheel. release.yml builds with python setup.py sdist, and build isn't in the prep step.

The package is pure Python, so nothing is broken — pip just builds the wheel locally on every install. But that needs a build toolchain on every install host, and it fails outright with --only-binary=:all:, against wheel-only internal mirrors, and in hash-pinned lockfiles. python setup.py sdist is deprecated in current setuptools as well.

This switches the build step to python -m build. No metadata changes; setup.py is untouched.

I checked the output against master first, since package_data={"tasktiger": ["lua/*.lua"]} is load-bearing — RedisScripts reads move_task.lua from the installed package at construction time:

$ python -c "import zipfile; print([n for n in zipfile.ZipFile('dist/tasktiger-0.25.0-py3-none-any.whl').namelist() if n.endswith('.lua')])"
['tasktiger/lua/move_task.lua', 'tasktiger/lua/semaphore.lua']

Both scripts are in the wheel, the sdist is unchanged (same 60 entries), and the wheel installs and constructs a TaskTiger in a clean venv. The flip side is worth knowing: moving this metadata into pyproject.toml under [project] silently drops the Lua files, which is why this leaves setup.py alone.

Since release.yml is workflow_dispatch under environment: production, this can't be exercised from a PR. Happy to follow up with a job in test.yaml that builds and imports the installed wheel if you'd like the packaging path covered on master.

Unrelated, but I was in the same files: #371 and #372 already cover the redis<5 constraint and croniter/pytz.