Improve deploy assumptions when creating tags

[sebastientaggart]

The Code Cannon /deploy skill assumes make bump-X will create a tag and pushes git push --tags afterward. When the bump silently fails to create the tag, git push --tags is a no-op and the deploy continues into the release-PR step with the wrong (or missing) tag.

A defensive improvement to the skill: after running the bump command, capture the expected new version (e.g. by re-reading package.json) and run git tag -l "v" to confirm the tag exists. If it doesn't, abort with a clear error pointing at the project's bump target. This catches Makefile bugs in any project that uses Code Cannon, not just this one.

[sebastientaggart]

#163 is related: the responsibility for this falls (or could, should?) to the scripts rather than the skill. The task remains the same though.

[sebastientaggart]

Resolution

The version-bump step of /deploy is now defensive: it runs the project's bump command, re-reads the version, confirms the matching vX.Y.Z tag was actually created (falling back to creating an annotated tag if the project's git config silently rejected a lightweight one), and only then pushes the commit and the tag. If anything goes wrong along the way the deploy stops with a clear error instead of silently continuing into the release step with a missing or mismatched tag.

A small unrelated rendering bug in the /deploy "set a specific version" example was also fixed, and the convention for the underlying config knob is now documented inline.

See #168 for full technical details.