fix(release): derive the version from the tag, completing #93's rung 1

[dmarx]

Rebased onto #93. This PR originally carried both rungs; #93 has since landed rung 2, so this is now only what #93 explicitly deferred:

Rung 1 would be better — derive the version from the tag with hatch-vcs, so there is only one source. Deliberately not bundled here: the publish checkout is actions/checkout@v4 at the default fetch-depth: 1 with no tags fetched, so switching without also setting fetch-depth: 0 would resolve to a 0.1.dev… version and fail the release a second time. Worth its own PR.

This is that PR, with the tag fetch that makes it safe. #93's assertion is kept untouched.

Why both rungs, not just #93's

DP-5's ladder puts derive the projection above guard the property, and rung 2 alone leaves two copies of one fact in place — it just makes their disagreement loud. Deriving removes the second copy; the guard then catches anything that could still go wrong (a shallow checkout, a build-backend change). They're complementary, not alternatives, and the workflow comment now says so.

The change

• pyproject.toml: dynamic = ["version"], hatch-vcs in build requires, [tool.hatch.version] source = "vcs".
• publish.yml: fetch-depth: 0 on the build checkout — git describe needs tags, and without this the derived version silently becomes a 0.1.dev… fallback, replacing a loud drift with a quiet one. This is precisely what fix(release): bump to 0.4.0, and make the tag and the version agree #93 flagged.
• No [tool.hatch.build.hooks.vcs] version file: nothing in the package reads its own version, and writing one out would reintroduce exactly the hand-maintained copy this removes.

Verification

case	result
clean checkout on the 0.4.0 tag	luria-0.4.0-py3-none-any.whl — no .devN, no local segment
working tree (untagged)	0.4.1.dev3+g0a80de972 — correctly unuploadable, PyPI rejects local segments
pip install -e .	works — dynamic version doesn't break dev installs
test suite	425 pass
luria lint	clean

A downstream data point

An adopting project was running pip install luria (0.3.0) while its CI pinned dmarx/luria/actions/generate@main. Local lint and CI lint were executing different code, with nothing in either reporting it — because pip install --upgrade luria is a no-op while the release is missing. That's the cost of the quiet failure mode, separate from the release itself being absent.

Notes

• The ADR keeps its temporary code, as docs: an ADR (Proposed) for the draft signal #88 did — luria concretize assigns the real number where merges serialize. (docs: an ADR (Proposed) for the draft signal #88's ADR-tmp3l17d is also still awaiting concretization on main.)
• The pyproject.toml comment refers to the decision by title rather than by code, since that file isn't in [luria.code] globs and a temp code there would never be concretized. Possibly pyproject.toml should just be added to the globs — worth a second opinion.
• Still doesn't ship 0.4.0. fix(release): bump to 0.4.0, and make the tag and the version agree #93's note applies unchanged: the tag points at a commit without any of this, so re-running the workflow rebuilds the same wheel. Either re-cut the tag at the new main or cut 0.4.1. I haven't touched the tag.