Versioned as portal: released by portal's publish job

iris reports its own version as the portal it matches; the tag, the
pin and the changelog line are written by portal's release step.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01L4jrCgLiKKHAEFuZUJjckH

README.md

@@ -39,15 +39,19 @@ what sits around those.
 ## Matching the site
 
 Every type iris reads is portal's own: portal is a library dependency
-pinned to a release tag in `Cargo.toml`, and `iris --version` says
-which. A content repo should run the iris that matches the portal
-release its site runs. Portal's own release tarball ships an `iris`
-binary built the same way, so a site that pins nothing extra has one
-at `/srv/app/<instance>/current/iris`.
+pinned to a release tag in `Cargo.toml`, and iris carries the same
+version number as that tag, so `iris v0.3.39` is the lint for portal
+v0.3.39 and nothing else. A content repo pins `IRIS_RELEASE` to the
+`PORTAL_RELEASE` its site runs. Portal's own release tarball ships the
+matching `iris` binary too, at `/srv/app/<instance>/current/iris`.
 
 ## Release
 
-Move the `Unreleased` lines in `CHANGELOG.md` under a heading for the
-version, bump `Cargo.toml`, commit, tag `v<version>`, push. CI builds
-the binary and attaches it to the Gitea release as `iris`, with that
-section as the notes.
+Iris is released by portal's publish job, never by hand: when a
+portal tag is pushed, that job re-pins this crate to the tag, sets
+the version to match, builds and tests it, adds the changelog line,
+and pushes the commit and the tag here. This repo's own CI then
+attaches the binary to the Gitea release as `iris`. A portal change
+to something the lint reads fails the portal release at that step.
+Changes to iris itself land on `main` between releases and ship with
+the next portal tag.