Make release verification resilient to PyPI challenges - #19

Summary

• keep rendered-page challenges strict by default while allowing release automation to defer only that browser-specific check
• verify PyPI JSON metadata, every release-pinned target, distribution hashes, and attestations before accepting the deferral
• add a manual recovery workflow that binds downloaded artifacts to the immutable tag commit and original tag-triggered release workflow
• create the GitHub Release only from the original verified distributions

v0.2.4 recovery scope

PyPI publication already succeeded in run 30522484949. This PR does not upload again, move the v0.2.4 tag, or rebuild artifacts. The recovery workflow downloads the original release-distributions artifact from that exact run and rechecks SHA256SUMS before public verification and GitHub Release creation.

Expected public artifact hashes:

• wheel: 3f5a239bbbd2f85217cf11f691fbb63f647092f67b82da4de38bd6907c5ab0f1
• sdist: 03f0e844df2c91deed5c211cdd2dd598d22f03d59d99cd8e792a58211c0b2296

Validation

• pytest tests/unit/test_pypi_release_verifier.py -q
• pytest tests/unit/test_packaging.py -q
• ruff check .
• ruff format --check .
• mypy src/miniverl
• python scripts/build_pypi_readme.py --check
• python scripts/check_markdown_links.py
• actionlint
• frozen benchmark SHA-256 unchanged