docs: swarm/services.md is one blurb per service, the host detail moves to the service's implementation page

Each service section lost its container, credential and metrics detail to a
Host setup section on its own implementation page, unchanged apart from links.
The four agentAuth option rows that sat above the page title moved into the
telemetry page's metrics option table.

docs/4-implementation/swarm/builder.md

@@ -681,3 +681,59 @@ is pure and runs in the container. Builds go to the host's nix daemon as an
 untrusted client: a config can set no daemon option, and its derivations build
 in the host's sandbox. A fixed-output derivation still has the network, as it
 does for any build on that host.
+
+## Host setup
+
+The swarm builder, in a `swarm-builder` container on the host that sets
+`deploy.builder.enable`. `allSwarmServices` defaults it on wherever the host
+has the builder's store identity, as for the other swarm services: the host
+that runs the store has it. Set `deploy.builder.enable = false` to opt out. It
+evaluates unreviewed config PRs and builds them through its host's nix daemon,
+from a container with its own network namespace.
+
+When an `agent-configs/<agent>` PR opens, reopens or gets a new push,
+swarm-controller queues a `build_agent` job. Jobs run one at a time, and a
+newer push replaces its PR's job while that job is still waiting. The builder
+builds that config at the PR's head on the agent base its own host runs,
+through the host's nix daemon, and swarm-controller writes the result as a `swarm-builder`
+commit status on the head. The job shows on the swarm UI's Jobs page. A red
+status blocks nothing: the merge still deploys.
+
+Separately, the builder builds each agent from `internal/meta` before the swarm
+sends its deploy, and a failed or unpushed build holds that deploy back (`build_meta` job;
+[deploy gate](#deploy-gate)). Those jobs share the one-build slot with
+the PR checks.
+
+It needs neither the forge nor a hive on its host. It reaches the queue, the
+secret store and the forge by name, under its own `builder` leaf, and fetches
+the private config repo with the read-only token of its own `builder` forge
+account. On a host without the store, that leaf is the one file to copy, as
+for the other swarm services.
+
+## Binary cache host setup
+
+The swarm's attic server, in a `swarm-attic` container on the host that sets
+`deploy.attic.enable`. `allSwarmServices` defaults it on wherever the host has
+the cache's store identity, as for the other swarm services: the host that runs the store has
+it. For an external cache, override `swarm.attic.{domain,cache}` and don't set
+`deploy.attic.enable` anywhere, or set it to `lib.mkForce false` under
+`allSwarmServices`.
+
+The container sits on the hive bridge in a network namespace of its own, and atticd
+listens on that namespace's loopback only; the gateway reaches it over a unix socket.
+The gateway serves it at `swarm.attic.domain` (default
+`attic.<swarm domain>`, on every host) over TLS, with no login in front, because attic checks
+its own tokens. Storage is local disk in the container's state.
+
+It needs no manual secret. Two host units, under the cache's own `attic` leaf,
+create its signing key, the cache and the push and pull tokens in the secret
+store, each only while absent. On a host without the store, that leaf is the one
+file to copy. The builder pushes green builds to it. How it works, and the
+external alternative, are in [Binary cache](#binary-cache).
+
+The container forwards atticd's journal to the swarm collector like the other
+service containers (see [Telemetry collector](telemetry.md#telemetry-collector-otel)). The two host
+units' lines reach the log store too: through the hive collector's journal
+allow-list on a hive host, or through the swarm collector's whole-journal
+receiver where the host runs that. A host with neither keeps them in its own
+journal.