A version somebody can read, instead of a sha nobody can

Updates follow a channel now. `stable` is the newest vX.Y.Z tag; `edge` is the
branch tip, which is what this did before. Stable is the default, because a
branch tip is not a release -- following one means deploying whatever was pushed
five minutes ago, possibly mid-feature, which is right for whoever builds this
and wrong for whoever runs it. The page can now say "running 1.0.0, 1.1.0
available" rather than showing two shas and leaving somebody to guess.

Read with git plumbing and never a forge API, for three reasons in the order
they bite. It would need a token on the deployment host -- a credential that can
reach the repository, sitting on a box, to answer a read-only question about
version numbers. It would tie this to one forge, so a fork on GitHub gets
nothing. And it breaks: checked against the Gitea this is developed on, `tea
whoami` works and `tea releases list` returns a 500 from a server-side panic
about token scopes, so a page resting on that endpoint would have shipped
already broken.

Release notes still travel, inside the annotated tag object, which
`git for-each-ref` reads with no API anywhere.

Two details that are only obvious after getting them wrong. A tag with a suffix
is not a release: git's version sort puts v1.1.0-rc1 *above* v1.1.0, so
accepting one would step a stable host onto a candidate on the strength of a
hyphen. And `--sort=-v:refname` rather than a lexical sort, which puts v1.9.0
above v1.10.0 and does it silently the first time a project reaches ten of
anything -- there is a test.

What is running is `git describe --tags --always`, so it reads "1.0.0" at a tag,
"1.0.0-7-gd4f56d" seven commits past one, and a bare sha before the first
release ever exists. That last case is what `--always` is for. When it lands
exactly on a tag whose name disagrees with __version__, the page says so: a tag
cut before the version bump names a release nobody can identify afterwards, and
the check costs no subprocess because both facts are already in hand.

update.sh resolves the channel the same way and detaches at the tag rather than
resetting -- a `reset --hard <tag>` while on main would move the local branch to
it, which is a rewrite of a ref nobody asked to rewrite. A host with no tags
falls back to the branch and says so, which is every host until the release.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

CLAUDE.md

@@ -20,7 +20,7 @@ lembas info                         # paths + counts, useful when confused
 lembas secret-key                   # generate LEMBAS_SECRET_KEY
 lembas create-admin                 # create or promote an admin
 
-pytest                              # 2081 tests, ~2min
+pytest                              # 2088 tests, ~2min
                                     # PLAN.md tracks what is and is not built
 ruff check .                        # lint (line length 100)
 python scripts/build_artwork.py     # regenerate artwork (SVG + PWA icons;
@@ -145,8 +145,8 @@ src/lembas/
     sharing.py       one visibility rule for every library store
     usage.py         what an account spent this month, and whether it may spend
                      more -- written even when the reply failed
-    updates.py       the running commit, the remote's, and the request file the
-                     helper watches for
+    updates.py       two channels (release tags, or the branch tip), what is
+                     running, and the request file the helper watches for
     prompts.py       every injected prompt fragment, and {{variables}}
     metrics.py       tokens, context percentage and tokens/second
     tokens.py        the chars/4 estimate, for endpoints that report none
@@ -1689,13 +1689,24 @@ install/update scripts. Every template is parameterised (`__PREFIX__`,
 `__SITE_HOST__`, …) and substituted at install time, so nothing host-specific is
 committed here. See `deploy/README.md`.
 
+**Updates follow a *channel*, not a commit.** `stable` is the newest `vX.Y.Z`
+tag, `edge` is the branch tip; a branch tip is not a release, and following one
+means deploying whatever was pushed five minutes ago. Read with git plumbing and
+never a forge API: a token on the deployment host to answer a read-only question
+is a bad trade, it ties this to one forge, and the Gitea API this was checked
+against 500s on exactly that endpoint. Release notes travel inside **annotated**
+tags, which `git for-each-ref` reads with no API anywhere. A tag with a suffix is
+not a release: git's version sort puts `v1.1.0-rc1` *above* `v1.1.0`, so
+accepting one would step a stable host onto a candidate on the strength of a
+hyphen.
+
 **The update button cannot do the work, and that is the design.** The service
 runs unprivileged and cannot restart itself; a web application that *can* is one
 whose worst day is much worse. So `/admin/updates` writes a file and an **opt-in**
 systemd `.path` unit runs `deploy/update.sh` as root. Three properties hold it
 together: the request file carries nothing that reaches a command line (the
-branch is baked into the unit at install time, so the button is always "deploy
-the branch this host was configured with"), it is off unless
+channel is baked into the unit at install time, so the button is always
+"deploy the channel this host was configured with"), it is off unless
 `INSTALL_UPDATE_HELPER=1`, and without it the page says so and prints the manual
 command. `services/updates.py` runs git with a fixed argv and `shell=False` --
 which is not the "nothing executes on this machine" rule being bent, since that