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.

docs/swarm/secrets.md

@@ -1,3 +1,5 @@
+| `swarm-builder`, in its container | `builderClientCertFile` / `builderClientKeyFile` | `swarm/services/builder/forge/token` and `swarm/services/<builder client id>/oidc/client` |
+
 # Swarm secrets: what exists, and where each one lives
 
 A swarm generates its credentials in three different places and reads them
@@ -400,9 +402,10 @@ next controller restart.
 ### Per-principal identities
 
 Bao matches a cert-auth role on the certificate's subject, so a certificate is an
-identity and sharing one merges the identities. Each of these seven leaves has
+identity and sharing one merges the identities. Each of these eight leaves has
 a role and a policy of its own, and reaches one path, except the review
-classifier's, the forge host's and Grafana's, which reach two each:
+classifier's, the builder's, the forge host's and Grafana's, which reach two
+each:
 
 | unit                                                | option pair under `deploy.bao.`                                    | reads, or writes                                                                                                              |
 | --------------------------------------------------- | ------------------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------- |
@@ -418,11 +421,11 @@ The first exists **per hive**, because the path it reads carries a hive name
 and every hive runs its own reader. Its subject is
 `<deploy.bao.queueAgentCommonNamePrefix>-<hive>`; `swarm.nix` reserves that
 composed spelling as a hive name, so nobody can name a hive into another hive's
-role. The other six reach a path that names a swarm service rather than a hive,
+role. The other seven reach a path that names a swarm service rather than a hive,
 so one role each is enough and their subjects are the flat
 `deploy.bao.grafanaOidcCommonName`, `deploy.bao.otelOidcCommonName`,
 `deploy.bao.forwarderOidcCommonName`, `deploy.bao.ciRunnerCommonName`,
-`deploy.bao.reviewClassifierCommonName` and
+`deploy.bao.reviewClassifierCommonName`, `deploy.bao.builderCommonName` and
 `deploy.bao.forgePublisherCommonName`. The last is the only writer, and the one
 leaf two units share: the forge's host holds one store identity for the token it
 publishes and the OIDC client secret it reads.