Prepare Gitea checkpoint container workflow

docs/TRUENAS.md

@@ -8,21 +8,39 @@ runtime prototype does not change public release or rules-mode gates.
 
 ## Checkpoint images
 
-Every push to `main` starts `.github/workflows/container.yml`. The Docker build
-runs the production build using the lockfile. Types, lint and offline tests
-remain part of source checkpoint verification rather than being repeated in
-the container build.
+The source repository is moving to [Gitea](https://git.juiced.computer/admin/Dune).
+Its `.gitea/workflows/container.yml` is intended to build and verify checkpoint
+images on pushes to `main`. Configure the Gitea Actions variables
+`DUNE_CONTAINER_IMAGE` for the full registry image name and
+`DUNE_REGISTRY_USERNAME` for the registry account; supply the registry token as
+the `CONTAINER_REGISTRY_TOKEN` Actions secret. The default image name is
+`git.juiced.computer/admin/dune`. Registry access and image visibility depend
+on the actual Gitea package settings; do not assume anonymous pulls work.
+
+No Gitea runner has been registered and no Gitea image build has succeeded yet.
+A source push is therefore not a verified container image or a deployment.
+Register and configure an `ubuntu-latest` runner whose job environment has a
+working Docker CLI, daemon and Buildx, plus network access to actions, npm and
+container images. Configure registry access, then verify the
+workflow and its published image before considering a manual NAS update. The
+existing Compose configuration continues to reference the GHCR image until a
+separately verified migration is applied at a safe point.
+
+The previous GitHub workflow, `.github/workflows/container.yml`, builds a
+production image using the lockfile on GitHub pushes. Types, lint and offline
+tests remain part of source checkpoint verification rather than being repeated
+in the container build.
 Before publishing, CI creates an isolated container and volume, checks accepted
 and rejected HTTP origins, verifies saved-seat restoration through restart and
 container replacement, then runs the HTTP integration suite.
 
-Only a passing image is pushed to `ghcr.io/quintine/dune:checkpoint`, alongside
-`ghcr.io/quintine/dune:sha-<full-commit>`. GitHub Actions builds; TrueNAS pulls the
-image. Failed checks leave the previous update tag untouched. This workflow
-targets Linux AMD64, the architecture of ordinary x86 TrueNAS systems.
+Only a passing GitHub image is pushed to `ghcr.io/quintine/dune:checkpoint`,
+alongside `ghcr.io/quintine/dune:sha-<full-commit>`. TrueNAS currently pulls
+that image. Failed checks leave the previous update tag untouched. This
+workflow targets Linux AMD64, the architecture of ordinary x86 TrueNAS systems.
 
-The user selected a **public image**, matching the existing public source
-repository, so TrueNAS needs no registry login. GitHub initially creates packages
+The user selected the existing GHCR image as **public**, matching the public
+source repository, so TrueNAS needs no registry login for that image. GitHub initially creates packages
 privately; after the first successful publication, set this package's visibility
 to public in GitHub package settings. Images contain application code and assets,
 never saved games or credentials. Publishing uses the workflow's built-in token.
@@ -93,8 +111,11 @@ See [NGINX WebSocket forwarding](https://nginx.org/en/docs/http/websocket.html).
 
 ### Applying an update
 
-1. Wait for the checkpoint workflow to succeed. Check for image updates in
-   TrueNAS and apply the update manually at a safe point between decisions.
+1. Wait for the checkpoint workflow for the configured image registry to
+   succeed and confirm the intended revision was published. A Gitea source
+   push alone is insufficient, and the GHCR Compose image does not automatically
+   switch registries. Check for image updates in TrueNAS and apply the update
+   manually at a safe point between decisions.
 2. Before updating, stop the app and back up or snapshot its persistent storage.
    Include the named volume in the Apps backup procedure; a dedicated host
    dataset provides a more explicit ZFS snapshot boundary.