Revert check/renovate to ubuntu-latest — brick-build's image has no Node

brick-build's job container (opensuse/leap:16.0) has no Node.js, and
every step in check/renovate (checkout, setup-ruby, setup-node) is a
JS-based Action that needs it just to start — both runs since the
brick-build switch failed immediately, and deploy never ran because it
depends on check passing. ubuntu-latest is shared with "Gitea Runner on
Cube" (not pinned to this specific machine), but that's fine: only
deploy (a unique label held by just brick's native runner) actually
needs to land on a specific box.

docs/deployment.adoc

@@ -7,9 +7,16 @@ MapTool deploys as a Podman container (via `podman compose`, driven by a
 the Gitea Actions runners run on. Two separate runners are registered
 against the Gitea instance:
 
-* The existing Docker-based runner (`gitea/runner:3`), label
-  `brick-build` — runs the `check` and `renovate` jobs in a fresh,
-  isolated container per job, same as before.
+* The existing Docker-based runner (`gitea/runner:3`), labels
+  `ubuntu-latest`/`ubuntu-24.04`/`ubuntu-22.04` — runs the `check` and
+  `renovate` jobs in a fresh, isolated container per job, same as
+  before. It's also registered under `brick-build`, but that label's
+  job container (`opensuse/leap:16.0`) has no Node.js, which every step
+  in `check`/`renovate` needs (they're JS-based Actions) — until that
+  image gets Node, or the label points elsewhere, `check`/`renovate`
+  stay on `ubuntu-latest`. That label is shared with "Gitea Runner on
+  Cube" too, so a `check`/`renovate` run isn't pinned to this specific
+  machine — harmless, since only `deploy` actually needs a specific box.
 * A dedicated native runner, installed directly on the host (no Docker
   around it), label `brick-host` — runs only the `deploy` job.