swarm-builder: build each agent config PR head and post a commit status

A new `swarm-builder` service, in its own container on the host that sets
`deploy.builder.enable` (defaulted on by `allSwarmServices` where the host
has the builder's store leaf, like the review classifier).

When an `agent-configs/<agent>` PR is opened, reopened or synchronized,
swarm-controller queues a `build_agent` jobq node. The node sets a
`swarm-builder` commit status to pending on the PR head, sends
`{agent, rev, pr}` to the builder over NATS request-reply
(`$SWARM.builder.build`), and writes success (store path), failure (last
line nix printed) or error (no builder / no reply) on the head. The node
fails when the build does, so the Jobs page matches the PR.

The builder builds nix/builder/check-flake's `check` with every input
overridden: hyperhive and nixpkgs to the host's own
`c0re.hyperhiveFlake`/`c0re.nixpkgsFlake` (what a hive there renders into
its meta flake), and the agent to the PR head on the forge. Evaluation is
pure and runs in the container; builds go to the host nix daemon as an
untrusted client. The private config repo is fetched with the token of a
new read-only `builder` forge account (in the `hives` team), which the
controller mints into `swarm/services/builder/forge/token`; git gets it
from a credential helper reading the child's environment, so it is in no
argument or URL.

Credentials: a `builder` store leaf minted by glue-bao-tls on the store
host, a `swarm-builder` reader policy (forge token + its own OIDC client
secret), an authelia machine client, and a `--builder-client` grant in the
queue's auth-callout responder. The controller gains a grant on the token
path and the secret publisher a deny on it.

This is the agent-config build check atlas scoped on #5081 (slice 3):
nothing is pushed to a cache, nothing is written to KV, and a red status
gates no deploy. The check composes agent-base + the config without the
values a hive adds (CA, docs, claude-code path, ports, input follows), so
it can disagree with a hive's own build.

swarm-builder/README.md

@@ -0,0 +1,31 @@
+# swarm-builder
+
+The swarm builder's build service, in the `swarm-builder` container on the
+host that sets `deploy.builder.enable`. The design is
+[`docs/swarm/builder.md`](../docs/swarm/builder.md).
+
+swarm-controller sends one request per config PR head: an agent, a commit and
+the PR. This service builds that agent config on the agent base this host was
+deployed with, through the host's nix daemon, and answers with the system
+closure's store path or the tail of what `nix` printed. The controller turns
+the answer into a `swarm-builder` commit status on the PR's head.
+
+## What a build is
+
+- `nix build` of `nix/builder/check-flake`'s `check` output, with its three
+  inputs overridden: `hyperhive` and `nixpkgs` to this host's own sources, and
+  `agent` to `git+https://<forge>/agent-configs/<agent>?ref=refs/pull/<pr>/head&rev=<rev>`.
+- The evaluation runs here, pure; the builds run in the host daemon's sandbox
+  as an untrusted client, so a config can neither set daemon options nor read
+  this service's environment.
+- Nothing is pushed and nothing is recorded: the closure stays in the host's
+  store until it is collected.
+
+## Credentials
+
+The container holds one credential: its own store certificate, which nspawn
+hands in at start without a copy on disk. With it the service reads its
+queue client secret at start and its read-only forge token at every build.
+`git` gets the token through a credential helper reading the child's
+environment, never in a URL or an argument. Its store role reads exactly
+those two paths.