fix(release): the package version and the tag that installs it must agree

[Polichinel]

Tag 1.1.0 was cut at main today while pyproject.toml still said 1.0.0. An install from that tag reports the previous release — and views-models#294's capability assert reads exactly that number to decide what the installed build can honour.

Caught before either launcher pinned, which is the only reason re-pointing the tag is cheap.

Why it ships with a guard, not just a bump

Third time in this arc a version has been declared in two places with a check on only one copy — same shape as the appwrite_env docstring edition and the blob-URL sha, both fixed in #249.

Two checks, in the two directions that differ:

check	when it runs	catches
tag matches the file	only when HEAD carries a release tag	a tag cut at a commit with the wrong number
newest tag not ahead of the file	every commit	the direction that actually bit — tag moved, file didn't

The reverse (file ahead of tag) is an ordinary pre-release bump and stays silent. Firing there would be the false alarm that gets a guard deleted (ADR-014 §3).

Mutation-proven both ways: reverting the file to 1.0.0 fails with the exact sentence describing today; setting it to 1.2.0 passes.

After merging

The tag needs re-pointing at the new main — nothing has pinned to it yet, so the window is clean:

git checkout main && git pull
git tag -f -a 1.1.0 -m "views-postprocessing 1.1.0 — the cross-repo guard surface"
git push --force origin 1.1.0

ruff check .    # clean
pytest -q       # 422 passed, 2 skipped, 40 xfailed

The second skip is the tag check on an untagged HEAD — correct here, and it will run once the tag is re-pointed.

🤖 Generated with Claude Code