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/development/security.md

@@ -693,8 +693,10 @@ public Dashboard login must be assessed with the actual edge/proxy controls befo
 
 ## Continuous integration boundary
 
-CI runs on self-hosted Gitea Actions runners. The inventoried server is **Gitea 1.24.2**, and that
-version determines which parts of the workflow are real guarantees and which are not.
+CI runs on self-hosted Gitea Actions runners. The server reports **Gitea 1.27.2** (`GET
+/api/v1/version`, checked 2026-10-06; this document previously said 1.24.2, which was stale). The
+server's actual version, not the documentation of an earlier one, determines which parts of the
+workflow are real guarantees and which are not.
 
 ### The current operating rule: trusted code only
 
@@ -727,24 +729,26 @@ so a later step in the same job cannot read or reuse it from there.
 It does **not** remove the short-lived `GITEA_TOKEN` from the job environment, and it does **not**
 reduce that token's server-side authority. A step that wants the token can still read it.
 
-### What Gitea 1.24 ignores — so the branch cannot claim it
+### What this server honours, and what is not yet verified
 
-Per the official comparison for this version
-(<https://docs.gitea.com/1.24/usage/actions/comparison>), Gitea 1.24's unsupported workflow syntax
-includes `permissions` and `jobs.<job_id>.permissions`, `concurrency`, and
-`jobs.<job_id>.timeout-minutes`. On this server those declarations are inert. Therefore:
+Each item separates what Gitea documents for 1.27
+(<https://docs.gitea.com/1.27/usage/actions/comparison>) from what has been observed on this server:
 
-- **The workflow's `permissions: contents: read` does not restrict the job token.** This branch
-  cannot claim the `GITEA_TOKEN` is read-only, because nothing in workflow YAML makes it so on
-  1.24. Job-token permission controls, repository/owner defaults, and server-side
-  maximum-permission clamping arrive in the 1.26 feature line
-  (<https://docs.gitea.com/1.26/usage/actions/token-permissions>).
-- **`concurrency` and `timeout-minutes` are not bounded-execution guarantees here.** Cancellation,
-  timeout, and teardown must be enforced by a trusted provisioner and reaper outside the workflow.
+- **`concurrency` is honoured.** Gitea supports it since 1.26 (go-gitea/gitea#32751), and on this
+  server a newer push to a pull request cancels the run it supersedes. Observed: Ekklesia run 133 was
+  cancelled when run 134 started for the same pull request, and run 135 when run 137 did. A
+  superseded run's own cleanup is therefore never guaranteed to run, which is one reason for the
+  stack sweep below.
+- **`permissions` is supported by 1.27, with Gitea's own scopes, but is not verified here.** The
+  server-side token-permission settings are not visible through the API, and nothing has yet proven
+  what the job token can and cannot do on this server. Until that proof exists (requirement 3
+  below), this repository still does not claim the `GITEA_TOKEN` is read-only.
+- **`timeout-minutes` is no longer listed as unsupported for 1.27, but is not verified here.**
+  Teardown does not rely on it: the stack sweep and a trusted reaper do.
+- **Still ignored:** `jobs.<job_id>.environment`, and any `runs-on` other than a single label.
 
-The declarations are kept deliberately: they are already correct for a supported Gitea release and
-for GitHub Actions, and keeping them means the upgrade does not require re-deriving the intent. They
-are documented as ignored, not removed.
+The declarations stay in the workflow either way: they state the intent, and are correct on GitHub
+Actions as well.
 
 ### Disposable stacks never outlive their job
 
@@ -793,16 +797,17 @@ they are not conditions on merging trusted, reviewed work.
 None of them can be satisfied by editing this repository; each requires access to the Gitea server
 and runner hosts, and each must be proven there.
 
-1. Upgrade Gitea to a reviewed supported release with job-token permission controls — at least the
-   1.26 feature line. Select the actual release during infrastructure work, after backup and
-   compatibility review; do not pin a version from this document.
+1. ~~Upgrade Gitea to a reviewed supported release with job-token permission controls — at least
+   the 1.26 feature line.~~ **Done:** the server runs 1.27.2. Items 2 and 3 now configure and prove
+   what it makes possible.
 2. Configure repository and owner defaults, and the server-side maximum permission, so workflow
    code cannot request more than read-only repository access.
 3. Prove against the real server that the job's `GITEA_TOKEN` cannot push code, create or update
    releases, packages, issues, or pull requests, change Actions configuration, or reach another
    private repository.
-4. Enforce job timeout, cancellation, concurrency, and teardown in the trusted
-   provisioner/reaper rather than relying on the ignored workflow keys above.
+4. Enforce job timeout and teardown in the trusted provisioner/reaper. `concurrency` is honoured
+   by the server; `timeout-minutes` is not yet verified, and the in-workflow stack sweep only
+   complements a reaper.
 5. Complete a disposable-guest runner isolation proof: one throwaway guest per job, torn down by a
    trusted reaper outside workflow YAML, holding no deployment credential, registration token, or
    reusable key.