CI: move workflow to .gitea/workflows/ (the instance is Gitea, not Forgejo)

The self-hosted git is gitea/gitea:latest (1.26), which reads
.gitea/workflows/ + .github/workflows/, not .forgejo/. Updated docs/ci.md
with the real enable steps (app.ini [actions], act_runner host-mode
register via `gitea actions generate-runner-token`, no web UI needed).

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015jtxAiu5dAW4WxCNdGkrkJ

.gitea/workflows/checkpoint.yml

@@ -3,11 +3,11 @@ name: checkpoint
 # Runs the full checkpoint suite (migrations, backend pytest, Godot smoke
 # tests, multiplayer, fresh-clone boot) on every push and PR.
 #
-# Requires a Forgejo Actions runner with:
+# Requires a Gitea Actions runner (act_runner) with:
 #   - Docker access (the suite starts an ephemeral Postgres via docker compose)
 #   - the Godot 4.6.2 headless binary at $HOME/godot/godot (or `godot` on PATH)
 #   - the backend Python deps installed (backend/requirements.txt)
-# A `host`-type runner on the AGP box already has all of this. See docs/ci.md.
+# A `host`-label runner on the AGP box already has all of this. See docs/ci.md.
 
 on:
   push:

docs/ci.md

@@ -1,53 +1,76 @@
 # CI
 
-`.forgejo/workflows/checkpoint.yml` runs the full checkpoint suite
+`.gitea/workflows/checkpoint.yml` runs the full checkpoint suite
 (`scripts/run_checkpoint_tests.py`: migrations on a fresh DB, backend
 `pytest`, all Godot smoke tests, the 2-player multiplayer test, and the
 fresh-clone boot check) on every push to `main` and every PR.
 
-**It does not run yet** — it needs a Forgejo Actions runner, which is a
+**It does not run yet** — the self-hosted Gitea instance (`git.cloudbison…`,
+Gitea 1.26) has Actions disabled and no runner registered. This is a
 one-time operator setup on the AGP host.
 
 ## Enabling it
 
-1. **Turn on Actions in Forgejo** — in the `forgejo` container's
-   `app.ini`, add:
+### 1. Turn on Actions in Gitea
 
-   ```ini
-   [actions]
-   ENABLED = true
-   ```
+Add to `/data/gitea/conf/app.ini` inside the `forgejo` container
+(host path `/DATA/AppData/forgejo/gitea/conf/app.ini`):
 
-   then restart the container.
+```ini
+[actions]
+ENABLED = true
+```
 
-2. **Register a `host` runner.** The suite starts Docker containers and runs
-   the Godot binary, so a container runner would need docker-in-docker + a
-   Godot image. A `host`-type runner (runs jobs directly on the AGP box,
-   where Docker, `~/godot/godot`, and Python already live) is simplest:
+then `docker restart forgejo`.
 
-   ```bash
-   # on the AGP host
-   FORGEJO_URL=http://localhost:3000
-   # get a token: Forgejo → Site Admin → Actions → Runners → Create
-   forgejo-runner register --no-interactive \
-     --instance "$FORGEJO_URL" --token "<token>" \
-     --name agp-host --labels host
-   forgejo-runner daemon &   # or a systemd unit
-   ```
+### 2. Register a `host` runner
 
-   Install `forgejo-runner` from
-   <https://code.forgejo.org/forgejo/runner/releases>.
+The suite starts Docker containers and runs the Godot binary, so a container
+runner would need docker-in-docker + a Godot image. `act_runner` in **host
+execution mode** runs jobs directly on the AGP box — where Docker,
+`~/godot/godot`, and Python already live.
 
-3. Push a commit — the `checkpoint` workflow should appear under the repo's
-   **Actions** tab.
+```bash
+# on the AGP host
+cd ~   # or wherever you keep the runner
+
+# 2a. binary
+curl -sL -o act_runner \
+  https://gitea.com/gitea/act_runner/releases/download/v0.2.13/act_runner-0.2.13-linux-amd64
+chmod +x act_runner
+
+# 2b. registration token (no web UI needed)
+TOKEN=$(docker exec forgejo gitea --config /data/gitea/conf/app.ini \
+          actions generate-runner-token)
+
+# 2c. register (host label -> jobs run directly on this machine)
+./act_runner register --no-interactive \
+  --instance http://localhost:3000 \
+  --token "$TOKEN" \
+  --name agp-host \
+  --labels host:host
+
+# 2d. run it (add a systemd unit for persistence)
+./act_runner daemon
+```
+
+`--labels host:host` means "a label called `host`, executed on the host".
+The workflow's `runs-on: host` then matches it.
+
+**Security note:** a host-mode runner executes whatever a workflow says,
+directly on the box, as the runner's user (which needs `docker` group
+membership). Fine for a single-maintainer private repo; revisit if the repo
+ever gets outside contributors.
+
+### 3. Push a commit
+
+The `checkpoint` workflow appears under the repo's **Actions** tab and gates
+merges.
 
 ## Interim: run it by hand
 
-Until the runner is up, the same gate is:
-
 ```bash
 python scripts/run_checkpoint_tests.py
 ```
 
-which is also what `/checkpoint/<PC>` on the dashboard runs before a
-playtest build.
+— also what `/checkpoint/<PC>` on the dashboard runs before a playtest build.