fix(ci): run install check after releases

[anisayakmitra-in]

Summary

• make the registry-consumer workflow callable from the release pipeline
• run it after the GitHub Release is created, instead of relying on an event emitted by GITHUB_TOKEN
• normalize a reusable caller's �X.Y.Z tag before querying crates.io

Closes #206.

Verification

• cargo test --workspace --all-features --lib
• cargo fmt --all -- --check
• git diff --check
• .github/scripts/check-dco.sh origin/main..HEAD
• .github/scripts/check-no-ai-attribution.sh origin/main..HEAD

Not run locally: the pinned zizmor audit, because this environment does not provide pipx; CI runs that audit at the repository's configured pedantic level.

[vyncint]

Thank you — this is a clean fix, and it solves the problem the issue actually described rather than the symptom.

I verified it rather than reading it, since a CI-only change can't be exercised by the suite:

The version normalization is load-bearing, not cosmetic. That was worth catching. Running both forms of the resolution over every trigger:

trigger	WANTED	TAG	before	after
workflow_call (this PR)	v0.8.0	—	v0.8.0	0.8.0
release: published	—	v0.8.0	0.8.0	0.8.0
workflow_dispatch	0.8.0	—	0.8.0	0.8.0
workflow_dispatch	v0.8.0	—	v0.8.0	0.8.0
schedule	—	—	query max_stable_version	same

Without the #v strip, the new caller would have queried /crates/termlens/v0.8.0, 404'd, and failed with "v0.8.0 never appeared on crates.io" — a confusing way to break the very gate being added. The dispatch path gained tag-form input for free.

The reusable call is wired correctly. The concurrency group resolves through inputs.version under workflow_call (github.event.release is null there, since the caller's event is the tag push), giving install-v0.8.0 — distinct from the caller's release-refs/tags/v0.8.0, so there's no self-deadlock. permissions: contents: read still restricts the inherited token, no secrets are needed, and needs: github-release puts it downstream of publish. It also matches the ci: reusable call already in that file, which is the right precedent to follow.

Everything else: all 11 checks pass including zizmor --persona=pedantic; DCO and the attribution policy pass on the commit itself; both workflows parse and the job graph is what it should be; RELEASING.md gains step 6 and has no manual footnote left, so the issue's "Done when" is fully met.

One nit, not worth a round trip: release.yml has a doubled blank line before the new job and none between its with: block and the comment introducing notify-testing-repo. The file's convention is comment-above-job so the meaning is unambiguous — I'll tidy the spacing next time that file is touched.

Merging. Thanks for picking up a good first issue and doing the careful version of it.