swarm-ci-runner: run the forge CI runner as a swarm service

The CI runner was a hive deploy module: hive-ci.nix ran it beside the
forge, and hive-c0re registered it through the forge's admin API with
the `core` token, writing the registration token through hive-priv. It
could only run on the forge's host, and it kept an admin-scoped forge
token on a hive.

Now the runner is a swarm service:

- swarm-ci-runner.nix runs it in a `swarm-ci-runner` container on the
  host that sets deploy.ci-runner.enable, reaching the forge by name.
  It needs neither the forge nor a hive there.
- swarm-controller reads the forge's runner registration token with its
  own admin token and writes it to swarm/services/ci-runner/
  registration-token whenever it differs from what it last wrote. Its
  grant on that path is create/update only.
- The runner's own leaf (CN swarm-ci-runner, role and policy of the same
  name) reads that one path. swarm-bao-ci-runner.service fetches it into
  the runner's EnvironmentFile and restarts the runner on a change.
- A pre-start step removes .runner when the daemon's journal since its
  last start holds Forgejo's "unregistered runner" refusal (the daemon
  exits 1 when its startup Declare gets it), or when .runner names
  another forge address; upstream's pre-start step then registers again.

Removed from the hive side: hive-ci.nix and deploy.forgejo.ci.*,
forge/ci_runner.rs, PrivRequest::RegisterCiRunner and its handler and
ReadWritePaths entry, InfraContainer::Ci with hivectl's --ci and the
dashboard's hive-ci journal entry, HYPERHIVE_FORGE_CI_ENABLED, and
read:admin,write:admin from CORE_TOKEN_SCOPES: nothing else in hive-c0re
calls /api/v1/admin/*. The old ci options, under both swarm.forge.ci and
deploy.forgejo.ci, now fail evaluation naming deploy.ci-runner.

The forge's half of the old ci.enable, the actions/checkout mirror and
DEFAULT_ACTIONS_URL = self, is deploy.forgejo.actionsFromSelf.

Closes #4954

hive-c0re/src/dashboard/journal.rs

@@ -1,8 +1,8 @@
 //! Journal-read endpoints for the dashboard.
 //!
 //! `GET /api/journal/{name}` reads a managed agent container's journal, OR
-//! one of the four hive infra services (`hive-ci`, `hive-forge`,
-//! `hive-gateway`, `hive-matrix` — [`hive_priv_sock::InfraContainer`] is the
+//! one of the three hive infra services (`hive-forge`, `hive-gateway`,
+//! `hive-matrix` — [`hive_priv_sock::InfraContainer`] is the
 //! allowlist). A container's journal is a `journalctl -M` read, delegated
 //! to the root helper since entering a machine needs privileges hive-c0re
 //! doesn't have; `hive-gateway` is nginx on the host, so it reads host
@@ -42,8 +42,8 @@ pub(super) struct JournalQuery {
 /// container namespace and needs root — is delegated to hive-priv.
 ///
 /// `name` is either a managed agent name (`iris`, optionally already
-/// carrying the `h-` prefix) or one of the four infra names (`hive-ci` /
-/// `hive-forge` / `hive-gateway` / `hive-matrix` — see
+/// carrying the `h-` prefix) or one of the three infra names (`hive-forge` /
+/// `hive-gateway` / `hive-matrix` — see
 /// [`hive_priv_sock::InfraContainer`]). Infra targets don't run the
 /// per-agent hive daemons, so `unit` is ignored for them — the whole
 /// machine journal, or for the gateway the host journal filtered to its
@@ -52,7 +52,7 @@ pub(super) struct JournalQuery {
     get,
     path = "/api/journal/{name}",
     params(
-        ("name" = String, Path, description = "agent name, or one of the four infra container names"),
+        ("name" = String, Path, description = "agent name, or one of the three infra container names"),
         JournalQuery,
     ),
     responses(