CI: back on the stable crafter-build Flatpak, now that 2.2.0 carries the Shader API

Crafter.Build 2.2.0 (2026-10-16) releases the Shader `defines` and
`variant` fields Crafter.Graphics master has used since 2026-10-06, so
CRAFTER_REF goes back to //stable and the toolchain moves only with a
Crafter.Build release again, the way imsd's package job has it. The
comments and the README now describe beta as the stopgap for the next
time Crafter.Graphics runs ahead of a release.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

deploy/README.md

@@ -1040,13 +1040,15 @@ sandbox, which is what CI's `crafter-run` wrapper does:
 
 Which branch of the Flatpak CI builds with is `CRAFTER_REF` at the top of
 `.forgejo/workflows/deploy.yaml`. `stable` is published from Crafter.Build's
-release tags, `beta` from every push to its master. The site tracks
-Crafter.Graphics master, and since 2026-10-06 that uses Shader fields that
-only Crafter.Build master has, so CI is on `beta` until a release carries
-them (`flatpak run --command=sh net.catcrafts.CrafterBuild//beta -c
-'crafter-build --version'` prints which master commit a beta is). Note that
-`flatpak install` of an already-installed ref is a no-op even when the remote
-has moved on; `flatpak update` is what moves it, and the workflow runs both.
+release tags, `beta` from every push to its master. CI is on `stable`, so the
+toolchain moves only with a Crafter.Build release. The site tracks
+Crafter.Graphics master, so a Crafter.Graphics change that needs a newer
+Crafter.Build API fails the deploy until that API is released (2026-10-12:
+the Shader fields 2.1.0 lacked, released in 2.2.0 four days later); `beta` is
+the stopgap, and `crafter-build --version` inside it prints which master
+commit it is. Note that `flatpak install` of an already-installed ref is a
+no-op even when the remote has moved on; `flatpak update` is what moves it,
+and the workflow runs both.
 
 ### If a `bin/` glob matches two directories