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>

src/lembas/config.py

@@ -38,11 +38,20 @@ class Settings(BaseSettings):
     session_ttl: int = 60 * 60 * 24 * 30
     request_timeout: float = 300.0
 
-    # Which branch `/admin/updates` compares against and the helper deploys.
-    # Deployment configuration and deliberately not an instance setting: it
-    # decides what code runs on this machine, and a value a web administrator
-    # could edit would turn "you may deploy the branch" into "you may deploy
-    # anything". `deploy/install.sh` writes it beside the rest.
+    # What `/admin/updates` compares against and the helper deploys.
+    #
+    # Deployment configuration and deliberately not instance settings: they
+    # decide what code runs on this machine, and a value a web administrator
+    # could edit would turn "you may deploy the channel" into "you may deploy
+    # anything". `deploy/install.sh` writes both beside the rest.
+    #
+    # `stable` follows the newest release tag; `edge` follows the branch tip.
+    # Stable is the default because a branch tip is not a release -- following
+    # one means deploying whatever was pushed five minutes ago, which is right
+    # for whoever is building this and wrong for whoever is running it.
+    update_channel: Literal["stable", "edge"] = "stable"
+    # Which branch is fetched, and which one `edge` follows. Stable needs it too:
+    # a fetch has to name a branch, and tags come down with it.
     update_branch: str = "main"
 
     @model_validator(mode="after")