Publish workflow: workflow_dispatch builds main instead of the release tag; no version-vs-tag guard; main version regressed to 0.4.0

## Summary

The PyPI artifact published today as `hssm 0.4.0` was **not built from the `v0.4.0` tag** — it was built from `main` at dispatch time, and contains code merged *after* the `v0.4.1` tag. Three separate problems in the publish pipeline line up to make this possible, and one of them will make the *next* publish fail outright.

## Evidence

Publish-workflow run history (`build_and_publish.yml`):

| When (UTC) | Trigger | Ref | Result |
|---|---|---|---|
| 2026-07-11 03:28 | `release` | v0.4.0 | cancelled (gate hang, #1061) |
| 2026-07-14 23:07 | `release` | v0.4.1 | cancelled (gate hang, #1061) |
| 2026-07-15 15:43 | `release` | v0.4.0 | cancelled (gate hang, #1061) |
| 2026-07-15 17:41 | **`workflow_dispatch`** | **`main`** | **success → published to PyPI** |

Verification of the published wheel (`pip install hssm==0.4.0` in a clean venv):
- `hssm.__version__ == "0.4.0"`, but the package contains `hssm.aDDM` (#967) **and `hssm._vi_compat` (#1059, merged 2026-07-14)** — i.e. content from `main` *after* the `v0.4.1` tag.
- Version strings across refs right now: `main` pyproject → `0.4.0`; `v0.4.1` tag → `0.4.1`; `v0.4.0` tag → `0.4.0`.

## The three problems

1. **`workflow_dispatch` publishes whatever branch it is dispatched on.** The `Checkout repository` step is `actions/checkout@v7` with no `ref:`; on a manual dispatch that resolves to `main`-at-dispatch-time, not a release tag. The manual dispatch exists as an escape hatch because the `release`-event runs keep being killed by the #1061 collection hang — so the escape hatch is currently the *only* path that works, and it silently changes what gets published.
2. **`main`'s version string regressed.** #1060 bumped pyproject to `0.4.1`, but `main` currently says `0.4.0` again (lost in a subsequent merge resolution). That is why the wheel self-reported 0.4.0 despite carrying post-0.4.1 content. It also means the **next dispatch-publish will try to re-upload `0.4.0` and be rejected by PyPI** (immutable versions).
3. **No guard that the built version matches the release tag.** Nothing fails the job when `pyproject.version` ≠ the tag being released, so mismatches ship silently.

## Suggested fixes

- In the publish workflow, check out the ref being released explicitly: `ref: ${{ github.event.release.tag_name }}` for `release` events, and add a required `tag` input for `workflow_dispatch` that is both checked out and validated.
- Add a pre-publish guard step: extract the version from the built wheel (or `pyproject.toml`) and assert it equals the tag name minus the `v` prefix; fail loudly otherwise.
- Bookkeeping now: restore `version = "0.4.1"` on `main`, and consider publishing a proper `0.4.1` so the mislabeled-but-functional `0.4.0` artifact is superseded (it cannot be replaced on PyPI).
- The underlying reason the tag-triggered runs keep dying is #1061 (HuggingFace download hang during pytest collection, 90-min timeout) — fixing that removes the pressure to use the dispatch escape hatch at all.

## Context

Found while pinning the Carney ARIA 2026 workshop materials to a PyPI release: the workshop needed 0.4.1-only features (per-parameter `noncentered`, the py3.14 PPC fix), and the "0.4.0" wheel unexpectedly contained them. Lucky this time; the failure mode is shipping unintended main-state under a stale version label.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Review build_and_publish.yml first, focusing on checkout behavior for release and workflow_dispatch events and the publish steps. Check pyproject.toml and the built wheel's version against the release tag, then verify that main reports 0.4.1 and that mismatched versions fail before publishing.

Written by the indexing model from the issue text.