feat: release from GitHub tag (hatch-vcs, no manual version bumps)

[arhangel66]

Summary

• Version sourced from git tags via hatch-vcs; no manual edits in pyproject.toml / __about__.py for releases
• Workflow triggers on release: published — create a GitHub release in UI → everything builds and ships
• workflow_dispatch kept as a fallback with build-only / github-release / full-release modes for ad-hoc runs (without a tag input)
• Removed version-validation step (no longer needed — tag is the source of truth)

How a release works now

1. Open Releases → Draft a new release in GitHub.
2. Create tag v0.0.8 on the target commit, write notes, click Publish release.
3. Workflow fires automatically and builds wheel + 4 binaries (linux-amd64/arm64, darwin-amd64/arm64) from the tagged sha.
4. Assets uploaded to the release; Python distributions published to PyPI.

Version 0.0.8 is baked into the wheel, lium --version, and asset names — no files edited.

Implementation notes

• pyproject.toml: dynamic = [\"version\"] + [tool.hatch.version] source = \"vcs\" + [tool.hatch.build.hooks.vcs] version-file = \"lium/_version.py\"
• local_scheme = \"no-local-version\" so PyPI accepts dev builds when needed
• lium/__about__.py now re-exports from the generated lium/_version.py with a 0.0.0+unknown fallback
• lium/_version.py added to .gitignore (written at build time by hatch-vcs)
• All checkout@v4 steps now use fetch-depth: 0 so hatch-vcs can see the tag/history inside Docker and macOS runners
• PyInstaller bundles _version.py as part of the lium package; get_version() fallback chain still honors LIUM_BUILD_VERSION

Stacked on

#58 and #59. Merge order: #58 → #59 → this.

Test plan

• uv sync locally populates lium/_version.py with a sensible dev version
• Manual workflow_dispatch with build-only passes (builds wheel + all binaries, no publish)
• Draft + publish v0.0.X-test on a throwaway commit → workflow publishes release assets + PyPI (TestPyPI if configured)
• lium --version of the freshly built binary shows 0.0.X-test