chore: update rhiza to v1.8.0

[tschm]

Syncs template-owned files from jebel-quant/rhiza, v1.7.2 → v1.8.0.

What changed

11 files, template-owned only:

• .github/workflows/rhiza_release.yml (+88/-4) — the substantive change. v1.8.0
  teaches the release workflow about dynamic versions: a dynamic/written probe now
  guards the uv version --short step (which exits 2 on a dynamic project), and a new
  "Verify built distribution matches the tag" step parses the dist/*.whl and
  dist/*.tar.gz filenames. That second check runs for written versions too, so it is
  a strict gain today.
• Makefile — rhiza-task@1.5.0 → rhiza-task@1.7.0.
• .pre-commit-config.yaml — hook bumps (ruff v0.16.5→v0.16.6, markdownlint
  v0.49.0→v0.49.1, uv-pre-commit 0.12.9→0.12.10).
• The six rhiza_*.yml stubs — reusable-workflow refs @v1.7.2 → @v1.8.0.
• .rhiza/template.yml + .rhiza/template.lock — the ref bump and new lock SHA.

Why now

This is the prerequisite for moving jquantstats to git-tag-derived versioning
(dynamic = ["version"] + hatch-vcs), which lands in follow-up PRs. Going dynamic on
the v1.7.2 workflow would fail the tag check after the tag is already pushed, and
would lose the guard against hatch-vcs silently building 0.1.dev1+g<sha> and
publishing it green.

Nothing in this PR changes release behaviour while the version is still written.

Notes

• Sync exited 0 — clean merge, no conflicts to resolve.
• Nothing was left unstaged; no repo-owned file was touched.
• The five dependabot-ahead action pins in rhiza_release.yml
  (checkout@v6.1.0, setup-python@v6.3.0, attest@v4.2.2,
  attest-build-provenance@v4.2.2) were verified intact after the merge — upstream
  still carries older pins, and the 3-way merge preserved ours.
• No gates were run — run /rhiza:quality for a scorecard.