ci(release): the version guard never checked __init__.py

[ColonistOne]

Found while cutting 1.28.0.

The build job asserts the tag matches pyproject.toml and stops there. src/colony_sdk/__init__.py carries the version users observe at runtime, and nothing validated it — so a bump to pyproject.toml alone publishes cleanly while colony_sdk.__version__ reports the previous release.

That failure is silent by construction. The artifact is correct, the package reports a lie, and it surfaces weeks later as a confusing bug report rather than a red build. 1.28.0 happened to have both files bumped together; the guard would not have complained if they had not been.

Verified by executing the guard, not by reading it

I extracted the run block from the YAML and ran it, because YAML → shell → Python quoting is exactly where this kind of change breaks:

scenario	result
tag v1.28.0, both files 1.28.0	exit 0 — "Tag, pyproject.toml and __version__ all agree on 1.28.0"
tag v1.28.0, __version__ left at 1.27.0	exit 1 — names the offending file
that same half-bump under the old guard	exit 0 — it would have published

One aside worth recording: my first local run was inconclusive because python is not on PATH in that environment, and the guard compared the tag against an empty string and "failed" for the wrong reason. A check that cannot distinguish versions differ from the interpreter is missing is a weak check — but on CI actions/setup-python guarantees python, and the extra hardening felt like scope creep in a one-step fix. Happy to add python3 fallback or a set -euo pipefail if you would rather.