ci: migrate Gitea workflows to .gitea and restore GitHub Pages in .github

Move the scheduled refresh and container-registry CI workflows into
.gitea/workflows/ so Gitea Actions runs them natively. Update
.github/workflows/ci.yml to build with BASE_PATH and deploy to GitHub
Pages upon push from the mirror sync, removing the Gitea-specific
container registry step. Update Dockerfile, .dockerignore, and test
harness to test and copy workflows from .gitea/.

.github/workflows/ci.yml

@@ -20,9 +20,9 @@ jobs:
     name: Typecheck, test, feed
     runs-on: ubuntu-latest
     steps:
-      - uses: https://github.com/actions/checkout@v4
+      - uses: actions/checkout@v4
 
-      - uses: https://github.com/oven-sh/setup-bun@v2
+      - uses: oven-sh/setup-bun@v2
         with:
           bun-version: "1.3"
 
@@ -33,10 +33,10 @@ jobs:
       # snapshots/*.state.json, so without this the feed built here has only
       # `contentChangedAt` to go on and every source reads as stale two days
       # after its bytes last moved, which for a wiki page is most of the time.
-      # Restore-only: refresh.yml owns writing this cache, and a miss just
-      # returns the pre-existing fallback behaviour.
+      # Restore-only: Gitea's refresh workflow owns writing this cache, and a
+      # miss just returns the pre-existing fallback behaviour.
       - name: Restore refresh bookkeeping
-        uses: https://github.com/actions/cache/restore@v4
+        uses: actions/cache/restore@v4
         with:
           path: snapshots/*.state.json
           key: refresh-state-
@@ -105,8 +105,8 @@ jobs:
     runs-on: ubuntu-latest
     needs: check
     steps:
-      - uses: https://github.com/actions/checkout@v4
-      - uses: https://github.com/oven-sh/setup-bun@v2
+      - uses: actions/checkout@v4
+      - uses: oven-sh/setup-bun@v2
         with:
           bun-version: "1.3"
       - run: bun install --frozen-lockfile
@@ -114,106 +114,44 @@ jobs:
       # This is the job whose output is deployed, so this is the one that must
       # see the refresh bookkeeping; see the same step in `check`.
       - name: Restore refresh bookkeeping
-        uses: https://github.com/actions/cache/restore@v4
+        uses: actions/cache/restore@v4
         with:
           path: snapshots/*.state.json
           key: refresh-state-
           restore-keys: refresh-state-
 
       - name: Build
-        # Built at the domain root, because the container image is what gets
-        # deployed and `serve.ts` serves from `/`. A BASE_PATH belongs here only
-        # if this artefact is ever hosted under a subpath again — it was set to
-        # /<repo>/ for GitHub Pages, which this pipeline no longer deploys to.
+        # Pages serves from /<repo>/ by default, so the app is built with a
+        # matching base href unless overridden by vars.BASE_PATH (e.g. for
+        # custom domains). Built at the domain root it would 404 on every asset.
+        env:
+          BASE_PATH: ${{ vars.BASE_PATH || format('/{0}/', github.event.repository.name) }}
         run: bun run build
-      - uses: https://github.com/actions/upload-artifact@v4
+      - uses: actions/upload-artifact@v4
         with:
           name: site
           path: public/
           retention-days: 7
 
-  image:
-    name: Container image
+  pages:
+    name: Deploy to Pages
     runs-on: ubuntu-latest
-    needs: check
-    # Pushing an image for every pull request fills the registry; do it where
-    # the artefact could actually be deployed.
+    needs: build
     if: github.ref == 'refs/heads/main' && github.event_name != 'pull_request'
     permissions:
-      contents: read
-      # Kept as a statement of intent, but it does not grant what this job
-      # needs: on Gitea the registry does not accept the Actions token at all,
-      # so `packages: write` on it authorises nothing. See the login step.
-      packages: write
+      pages: write
+      id-token: write
+    environment:
+      name: github-pages
+      url: ${{ steps.deploy.outputs.page_url }}
     steps:
-      - uses: https://github.com/actions/checkout@v4
-
-      - uses: https://github.com/docker/setup-buildx-action@v3
-
-      - name: Lowercase image name
-        id: img
-        # Gitea's container registry, like GHCR before it, rejects any uppercase
-        # in a repository name, and github.repository preserves the owner's
-        # casing verbatim. The host is read from github.server_url rather than
-        # hardcoded, so a fork on another Gitea instance pushes to its own
-        # registry instead of this one.
-        env:
-          SERVER_URL: ${{ github.server_url }}
-        run: |
-          host="${SERVER_URL#https://}"
-          host="${host#http://}"
-          host="${host%%/*}"
-          # Two outputs on purpose: login wants the bare host, the tags want the
-          # full path. Passing the full path as the registry authenticates
-          # against a host that does not exist.
-          echo "host=${host}" >> "$GITHUB_OUTPUT"
-          echo "name=${host}/${GITHUB_REPOSITORY,,}" >> "$GITHUB_OUTPUT"
-
-      # Why not `secrets.GITHUB_TOKEN`, which is what this was and what the
-      # GHCR version used: a Gitea package belongs to a **user or org owner,
-      # not to a repository**, so the ephemeral repo-scoped Actions token
-      # carries no authority over it and the registry refuses it. GitLab hands
-      # out working per-job registry credentials ($CI_REGISTRY_PASSWORD, which
-      # .gitlab-ci.yml uses) and Gitea deliberately does not, so this needs a
-      # real access token with package write scope, stored as REGISTRY_TOKEN.
-      #
-      # The username must be the token's owner, hence repository_owner rather
-      # than github.actor: the image is pushed into the owner's namespace, and
-      # actor is whoever happened to trigger the run — a different person on a
-      # dispatch, and the wrong account entirely on a fork.
-      - name: Check the registry credential exists
-        # Without this the failure is a bare `unauthorized` from the daemon,
-        # which says nothing about what to do. It also tells us something we do
-        # not currently know: whether the old token was rejected or was simply
-        # never set.
-        env:
-          REGISTRY_TOKEN: ${{ secrets.REGISTRY_TOKEN }}
-        run: |
-          if [ -z "${REGISTRY_TOKEN:-}" ]; then
-            echo "::error::REGISTRY_TOKEN is not set. Create an access token at" \
-                 "${{ github.server_url }}/user/settings/applications with the" \
-                 "package read+write scope, then add it to this repository under" \
-                 "Settings → Actions → Secrets as REGISTRY_TOKEN."
-            exit 1
-          fi
-          echo "REGISTRY_TOKEN is set (${#REGISTRY_TOKEN} chars)"
-
-      - uses: https://github.com/docker/login-action@v3
+      - uses: actions/download-artifact@v4
         with:
-          registry: ${{ steps.img.outputs.host }}
-          username: ${{ github.repository_owner }}
-          password: ${{ secrets.REGISTRY_TOKEN }}
-
-      - uses: https://github.com/docker/build-push-action@v6
+          name: site
+          path: public
+      - uses: actions/configure-pages@v5
+      - uses: actions/upload-pages-artifact@v3
         with:
-          context: .
-          push: true
-          tags: |
-            ${{ steps.img.outputs.name }}:latest
-            ${{ steps.img.outputs.name }}:${{ github.sha }}
-          # Registry cache rather than `type=gha`. Gitea does expose the Actions
-          # cache API, but buildx's gha backend is the least reliable corner of
-          # that compatibility surface, and we are already authenticated to a
-          # registry that can hold the layers.
-          cache-from: type=registry,ref=${{ steps.img.outputs.name }}:buildcache
-          cache-to: type=registry,ref=${{ steps.img.outputs.name }}:buildcache,mode=max
+          path: public
+      - id: deploy
+        uses: actions/deploy-pages@v4