Deploy from a dedicated runner on Chronicles-AB

The workflow now runs on the aws-deploy label: an act_runner container on the
Gitea NAS, registered for this repo only. The checklist app's nas runner on
Chronicles-NA is no longer involved.

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

.gitea/workflows/deploy.yml

@@ -1,10 +1,12 @@
 # Push to main -> Waters Boards is rebuilt on the AWS Lightsail box.
 #
-# Runs on the "nas" act_runner, which lives inside the church network and can reach the
-# internet. (The Gitea server isn't reachable from outside, so AWS can't pull from it; the
-# runner pushes to AWS instead.) It syntax-checks the code, rsyncs server/ and deploy/aws/ to
-# /opt/waters-boards on the box over SSH, rebuilds in place and waits for the healthcheck.
-# All of that is deploy/aws/deploy.sh, the same script you run from a laptop.
+# Runs on the "aws-deploy" act_runner: a container on Chronicles-AB (the Gitea NAS) in
+# /volume2/docker/gitea-runner-boards, registered for this repo only. It lives inside the
+# church network because the Gitea server isn't reachable from outside, so AWS can't pull
+# from it; the runner pushes to AWS instead. It syntax-checks the code, rsyncs server/ and
+# deploy/aws/ to /opt/waters-boards on the box over SSH, rebuilds in place and waits for the
+# healthcheck. All of that is deploy/aws/deploy.sh, the same script you run from a laptop.
+# The checklist app's "nas" runner on Chronicles-NA is not involved.
 #
 # ONE-TIME SETUP before the first run (see README.md › Deploy to AWS):
 #   1. Make a deploy-only SSH key (e.g. ssh-keygen -t ed25519 -N '' -f deploy_key) and add the
@@ -17,8 +19,9 @@
 #        DEPLOY_ENABLED      true
 #      Until DEPLOY_ENABLED is true this job is skipped, so pushes made before the box is
 #      ready don't show as failures.
-#   4. The "nas" runner must be registered where it can see this repo (user- or instance-level,
-#      not only on the checklist repo).
+#   4. The runner: on Chronicles-AB, /volume2/docker/gitea-runner-boards/start-runner.sh
+#      (re)creates it. Its runner.env holds a registration token scoped to this repo, minted
+#      with: docker exec -u git gitea gitea actions generate-runner-token --scope christian/waters-boards
 # /opt/waters-boards/.env must already exist on the box. The deploy never creates or
 # overwrites it, and never touches data/.
 
@@ -36,7 +39,7 @@ on:
 jobs:
   deploy:
     if: ${{ vars.DEPLOY_ENABLED == 'true' }}
-    runs-on: nas
+    runs-on: aws-deploy
     container:
       image: node:22-alpine
 

README.md

@@ -127,8 +127,10 @@ healthcheck, and prints what `https://boards.watersmedia.org/healthz` returns. S
 to deploy to a host other than `boards-aws`.
 
 **Deploy from Gitea Actions.** The Gitea server is only reachable from inside the church network,
-so AWS can't pull from it. Instead the `nas` runner, which is inside the network and can reach
-the internet, runs the same `deploy.sh` and pushes to the box over SSH. The workflow
+so AWS can't pull from it. Instead a runner inside the network runs the same `deploy.sh` and
+pushes to the box over SSH. That runner is a container on Chronicles-AB (the NAS that hosts
+Gitea), in `/volume2/docker/gitea-runner-boards`, registered for this repo only with the label
+`aws-deploy`. The checklist app's `nas` runner on Chronicles-NA is separate and untouched. The workflow
 (`.gitea/workflows/deploy.yml`) runs on every push to `main` that touches `server/` or
 `deploy/aws/`, or by hand from the Gitea Actions tab. One-time setup:
 
@@ -140,8 +142,10 @@ the internet, runs the same `deploy.sh` and pushes to the box over SSH. The work
 3. In **Settings → Actions → Variables**, add `DEPLOY_HOST` (the static IP) and
    `DEPLOY_ENABLED` = `true`. Until `DEPLOY_ENABLED` is `true`, the deploy job is skipped, so
    pushes made before the box was ready don't show as failures.
-4. The `nas` runner must be registered where it can see this repo (user- or instance-level, not
-   only on the checklist repo).
+4. If the runner ever needs rebuilding: on Chronicles-AB, `start-runner.sh` in that folder
+   recreates the container. To register it afresh, delete `.runner` there, put a new token in
+   `runner.env` (`docker exec -u git gitea gitea actions generate-runner-token --scope
+   christian/waters-boards` on that NAS), and run the script again.
 
 **What a deploy never touches:** `data/` and `.env`. It deletes nothing on the box. It rebuilds
 without taking the running container down first, so a failed build leaves the old version