docs: the server runs Gitea 1.27.2, not 1.24.2; say what it actually honours

The CI documentation, the workflow header, the README, ADR 0047 and the
sweep's comment all said the server was Gitea 1.24.2, which ignores
`permissions`, `concurrency` and `timeout-minutes`. The server reports
1.27.2 (GET /api/v1/version).

Each claim is now stated from what is verified on this server:
- `concurrency` is honoured, observed: Ekklesia runs 133 and 135 were
  cancelled when a newer run started for the same pull request;
- `permissions` is supported by 1.27 with Gitea's own scopes, but the
  token's actual authority is not visible through the API and not yet
  proven, so nothing claims the job token is read-only;
- `timeout-minutes` is no longer listed as unsupported, but is not
  verified, and teardown still relies on the stack sweep and a reaper.

Requirement 1 for executing untrusted contributions (upgrade to the
1.26 line or later) is marked done; items 2 and 3, configuring and
proving token authority, remain. ADR 0047 (still Proposed) restates
its "docker run, not a reusable workflow" reasons for 1.27, where
private sources are supported. The reasons still hold without the 1.24
argument.

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

docs/architecture/decisions/0047-module-ci-harness.md

@@ -163,27 +163,28 @@ It references no secret, needs no registry credential (the harness image is publ
 organization), and uses no `pull_request_target`. The trusted-code-only rule for self-hosted runners
 applies to module repositories exactly as it does to the platform (see `docs/development/security.md`).
 
-**Why `docker run`, and not a reusable workflow or a composite action.** The inventoried server is
-Gitea 1.24.2.
+**Why `docker run`, and not a reusable workflow or a composite action.** The server runs Gitea
+1.27.2. (This proposal first assumed 1.24.2; the reasons below hold on the actual version.)
 
-- Its runner does support calling a reusable workflow from another repository, by cloning that
-  repository. That support is thinly documented, and has known problems in practice.
-- Actions and reusable workflows from **private** repositories only arrive with Gitea 1.26
-  (go-gitea/gitea#32562).
+- Its runner can call a reusable workflow from another repository by cloning that repository, and
+  since 1.26 that includes private repositories (go-gitea/gitea#32562). That support is still thinly
+  documented, and has known problems in practice.
+- A reusable workflow would make the harness's behaviour depend on how this server and runner
+  version expand it. An image runs the same everywhere it runs.
 - Composite actions from another repository work through absolute `uses:` URLs. That would still
   wrap the same `docker run`, adding a second pinned reference and nothing else.
 
 An image digest is the one reference that is equally immutable, equally reviewable, and works
-unchanged on Gitea 1.24, Gitea 1.26, and GitHub Actions. A composite action can be added later as a
+unchanged on any Gitea release and on GitHub Actions. A composite action can be added later as a
 convenience over the same image, without changing what a module pins.
 
 ### Nothing the harness starts outlives the job that started it
 
 The harness starts Docker stacks on a shared runner, and a runner can kill a job outright: a
-cancelled job, or the runner's own time limit, since Gitea 1.24 ignores `timeout-minutes`. A script's
-own cleanup trap does not run then. The platform's CI leaked a whole migration stack that way, and it
-ran until someone removed it by hand. So the harness follows the platform's rule
-(`scripts/ci-sweep.sh`, `docs/development/security.md`):
+cancelled or superseded job (`concurrency` cancels superseded runs on this server), or the runner's
+own time limit. A script's own cleanup trap does not run then. The platform's CI leaked a whole
+migration stack that way, and it ran until someone removed it by hand. So the harness follows the
+platform's rule (`scripts/ci-sweep.sh`, `docs/development/security.md`):
 
 - everything it starts is named and labeled as a CI stack of its run, attempt, and job key;
 - it removes its own stacks in a trap;
@@ -233,9 +234,9 @@ The registry is reached exactly as the instance's publish job reaches it.
 
 - **Each module keeps its own copy of the smoke scripts.** Rejected. That is today's situation in
   embryo, and it drifts.
-- **A reusable workflow in the platform repository.** Rejected for now, for the Gitea 1.24 reasons
-  above. It would also give the harness's behaviour to whichever runner and server version happens
-  to expand it.
+- **A reusable workflow in the platform repository.** Rejected for now, for the reasons above: thin
+  support in practice, and a harness whose behaviour depends on whichever runner and server version
+  happens to expand it.
 - **Publish the harness as an npm package.** Rejected. The harness needs Docker, a browser, and the
   platform's deployment files anyway, so a package would ship a fraction of it and assume the rest.
 - **Test only the newest platform version.** Rejected. A module's range floor would go untested