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>

deploy/README.md

@@ -45,13 +45,39 @@ Everything is overridable from the environment:
 | `HOME_DIR` | `/home/lembas` | that account's home |
 | `PREFIX` | `/srv/lembas` | install root (bind mount of `HOME_DIR`) |
 | `REPO_URL` | this checkout's `origin` | so a fork deploys itself |
-| `LEMBAS_BRANCH` | `main` | branch to deploy, and what `/admin/updates` compares against |
+| `LEMBAS_BRANCH` | `main` | branch to fetch, and what the `edge` channel follows |
+| `LEMBAS_CHANNEL` | `stable` | `stable` follows release tags, `edge` follows the branch tip |
 | `INSTALL_UPDATE_HELPER` | `0` | `1` lets the web interface deploy that branch as root |
 
+## Channels
+
+| | follows | for |
+|---|---|---|
+| `stable` (default) | the newest `vX.Y.Z` tag | anybody running this |
+| `edge` | the tip of `LEMBAS_BRANCH` | whoever is building it |
+
+**A branch tip is not a release.** Following `main` means deploying whatever was
+pushed five minutes ago, possibly mid-feature — right for development and wrong
+for a machine somebody depends on. Stable is the default for that reason.
+
+A tag with a suffix (`v1.1.0-rc1`) is deliberately **not** a release: git's
+version sort puts it *above* `v1.1.0`, so accepting one would step a stable host
+onto a release candidate on the strength of a hyphen. A prerelease is something
+you check out by name.
+
+Release notes travel inside **annotated** tags, so `git tag -a v1.1.0 -m "…"` is
+what puts them on the update page. No forge API is involved anywhere — which
+matters more than it sounds: a token on the deployment host to answer a
+read-only question about version numbers is a bad trade, it would tie this to
+one forge, and the Gitea API this was checked against returns a 500 from a
+server-side panic on exactly that endpoint.
+
 ## Updating from the web interface
 
-`/admin/updates` says what is running, what is on the branch and what changed
-between. **Checking** reaches the remote; opening the page does not.
+`/admin/updates` says what is running (`git describe`, so `1.0.0` at a tag and
+`1.0.0-7-gd4f56d` seven commits past one), what the channel offers, the release
+notes, and the commits between. **Checking** reaches the remote; opening the page
+does not.
 
 The button is opt-in, and the reason is a boundary rather than caution:
 
@@ -61,17 +87,16 @@ INSTALL_UPDATE_HELPER=1 SITE_HOST=chat.example ./deploy/install.sh
 
 That installs `lembas-update.path` and `lembas-update.service`. The web
 interface writes `$PREFIX/data/update-requested`; the path unit notices and the
-service runs `update.sh` **as root**.
+service runs `update.sh` **as root**, on the configured channel.
 
 **What that grants.** Anybody who can administer this web interface can then
 deploy whatever is on the configured branch and restart the service. That is the
 point of it, and it is why it is not the default.
 
 **What it deliberately does not grant.** The request file carries nothing that
-reaches a command line — no branch, no ref, no arguments. The branch is baked
-into the unit at install time from `LEMBAS_BRANCH`, so the button is always
-"deploy the branch this host was configured with" and never "deploy something
-else". Re-running the installer without the flag removes both units and the
+reaches a command line — no ref, no branch, no channel, no arguments. Both are
+baked into the unit at install time, so the button is always "deploy the channel
+this host was configured with" and never "deploy something else". Re-running the installer without the flag removes both units and the
 marker, and the page goes back to printing the manual command.
 
 Without the helper the page says so and shows `sudo …/deploy/update.sh`, which is