feat: Gitea CI, and releases built once, previewed and promoted as one file

ci.yml runs tools/check.sh and the container gate on every push and pull
request, with no secrets. Release 1 builds a version from its release
commit on master or release/*, gates it, and keeps it in a Gitea
pre-release. Release 2 gates that file again on the CI runner and
publishes it to canary (Preview) from the release runner. Release 3
promotes the file Preview ran, on a person's approval. Import records a
release from before Gitea kept the record. All of it is
tools/release-ci.sh calling the existing scripts.

docs/releasing.md: tracks, branches, each step, immutability, rollback,
secrets, runners, Nightly and the hardware lab as designs, the Gitea
administration still to do, and what was measured to make it.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

docs/provisioning.md

@@ -199,11 +199,15 @@ version newer than its own. So now:
 A publish that fails after the local copy into `repo/packages` has spent
 that number. Use the next one.
 
-### Canary
+### Canary (Preview)
+
+Since 0.2.6.6 releases normally go through Gitea: built once, recorded as
+a Gitea release, published and promoted by workflows that call these same
+scripts. [releasing.md](releasing.md) has the whole path. By hand:
 
 ```
-./update_canary.sh 0.2.6.1        # a maintenance release
-./update_canary.sh 0.2.7          # the next feature release
+./update_canary.sh 0.2.6.7 dist/ekklesia-classroom_0.2.6.7_amd64.deb   # gate and publish THAT file
+./update_canary.sh 0.2.7                                               # build, gate and publish
 ```
 
 The version is always given. With four parts there are two possible next
@@ -211,17 +215,24 @@ numbers, and which one a release is depends on what is in it. Run with no
 argument it prints the current canary and both candidates, and builds
 nothing.
 
+Given a package, that file is what is gated and published; nothing is
+rebuilt, because a second build is a second, untested file. The gate is
+`tools/release-gate.sh`: a fresh install, and the upgrade from whatever
+canary and stable serve, each on a room of that channel;
+`RELEASE_GATE_FROM=0.2.2` adds an older release rooms are still on.
+
 ### Stable
 
 ```
-./update_stable.sh 0.2.6.1
+./update_stable.sh 0.2.6.6 <sha256>
 ```
 
 Only with the owner's written approval for that release. Stable is never
 given a package of its own: it is pointed at one canary already published,
 byte for byte, and refuses a version that is not newer than stable's
 current one or whose package the server does not hold with the same
-checksum.
+checksum. With the sha256 — always give it — it refuses any file but the
+one that was approved.
 
 ### Checking a channel without changing it