Deploy to brick-host instead of cube-host

cube.local and brick.local swapped IPs and brick is now the deploy
target — rename the native runner label everywhere it's referenced.

.gitea/workflows/ci.yml

@@ -34,13 +34,13 @@ jobs:
         run: find public/js -name "*.js" -print0 | xargs -0 -n1 node --check
 
   # Handled by a separate, native (non-Docker) runner registered with the
-  # single "cube-host" label (see docs/deployment.adoc) — it runs directly
+  # single "brick-host" label (see docs/deployment.adoc) — it runs directly
   # on the server, so it has podman/git/etc. from the host, no socket/bind
   # mount tricks needed. The Docker-based runner keeps handling `check`.
   deploy:
     needs: check
     if: github.event_name == 'push' && github.ref == 'refs/heads/main'
-    runs-on: cube-host
+    runs-on: brick-host
     steps:
       # Not actions/checkout@v4: keeping this plain-git checkout from when
       # the job ran in a Node-less container — no reason to add a Node
@@ -114,14 +114,14 @@ jobs:
       # layers (apt-get/bundle install) as cache — unlike explicitly
       # removing the image first, which would delete that cache along with
       # it. sudo is needed since the unit is root's, not gitea-runner's own
-      # (gitea-runner has passwordless sudo for this on cube-host).
+      # (gitea-runner has passwordless sudo for this on brick-host).
       - name: Deploy
         run: sudo systemctl restart podman-compose@maptool.service
 
       # systemctl restart above only confirms the process forked
       # (Type=simple, no readiness protocol) — not that `podman compose up
       # --build` actually finished and Puma is answering. Polls the health
-      # endpoint (cube-host itself, same machine the container's port is
+      # endpoint (brick-host itself, same machine the container's port is
       # published on) instead of trusting that — checking for this
       # deploy's own revision, not just any 200, so a stuck old container
       # that never got torn down can't pass as a successful deploy of the

docs/deployment.adoc

@@ -11,7 +11,7 @@ against the Gitea instance:
   `ubuntu-latest`/`ubuntu-24.04`/`ubuntu-22.04` — runs the `check` job
   in a fresh, isolated container per job, same as before.
 * A dedicated native runner, installed directly on the host (no Docker
-  around it), label `cube-host` — runs only the `deploy` job.
+  around it), label `brick-host` — runs only the `deploy` job.
 
 They're separate because the Docker-based runner's jobs (whether in
 its usual isolated per-job containers, or tried directly inside its
@@ -84,7 +84,7 @@ label:
 ----
 runner:
   labels:
-    - "cube-host"
+    - "brick-host"
 ----
 
 The `host` scheme means jobs run directly via the runner process's own
@@ -237,7 +237,7 @@ webhook simply won't receive that session; nothing breaks.
 == CI deploy job
 
 `.gitea/workflows/ci.yml`'s `deploy` job runs after `check` passes, only
-on a push to `main`, with `runs-on: cube-host`:
+on a push to `main`, with `runs-on: brick-host`:
 
 . Checks out the repo with plain `git` (`fetch` + `checkout`,
   authenticated via a one-off `http.extraHeader`) rather than