bao: write the swarm controller's policy from inside the store

Cert auth answers a role, so nothing in the swarm can authenticate to
the store until some role exists. Creating the first one therefore
cannot itself use a certificate — the credential has to come from
outside that cycle, and an operator places it.

`deploy.bao.bootstrapTokenFile` names that token. A one-shot unit inside
the store's container reads it and writes the `swarm-controller` policy;
`local-defaults.nix` supplies the path (never the file) on an all-local
deploy, since co-location makes only the location derivable. `bao
operator init` stays an operator action in every shape.

The unit runs in the container rather than on the host because writing
the first grant is a store-side operation: it reaches the store locally
and needs no client certificate. Gating it on the store being here is
therefore not the co-location assumption glue-matrix-bao-token.nix
warns about — a reader has to work from anywhere, the first write never
does.

Policy only, deliberately: a cert-auth role binds a certificate and the
controller has no bao identity yet — it holds no leaf and contains no
bao code at all. The two certificates that do exist are both wrong to
bind. `clientCertFile` is the store host's own reader leaf rather than
the controller's, and the CA that signed it also signs every other
reader's, so binding that would let any reader authenticate as the
controller. Whoever gives the controller an identity writes the role.

The grants are scoped to `hive-*`. Without the prefix the controller
could rewrite the policy that constrains it.

Two things the module-eval arms pin: the unit renders inside the
container with the token path in both its script and its
ConditionPathExists, and a host that names a token while running no
store gets neither the unit nor the host-side directory.

The capabilities were derived with `bao write -output-policy` rather
than written from memory, and the setup.md commands were run against a
real binary for shape before being written down.

Refs #3726.

docs/getting-started/setup.md

@@ -56,6 +56,31 @@ never initialised. Do this before anything is pointed at it.
 bao operator init   # keep the keys it prints and the root token OFF this host
 ```
 
+While you still hold that root token, mint the one credential the swarm needs
+to grant itself anything. Cert auth answers a _role_, so nothing can
+authenticate until some role exists — this token is what breaks that cycle,
+and it's the only step that needs the root token.
+
+```bash
+# A policy that can write exactly one policy, and nothing else.
+bao policy write swarm-bootstrap - <<'EOF'
+path "sys/policies/acl/swarm-controller" {
+  capabilities = ["create", "update"]
+}
+EOF
+
+# A token holding it. `-orphan` so it outlives the session that made it.
+bao token create -policy=swarm-bootstrap -ttl=24h -orphan -display-name=swarm-bootstrap
+```
+
+Put the token's value at `services.hyperhive.deploy.bao.bootstrapTokenFile`
+(all-local names that path for you), then rebuild. A one-shot unit inside the
+store's container reads it and writes the `swarm-controller` policy.
+
+**Delete the file once that has run.** The unit skips when it's absent, so a
+host that has finished bootstrapping stops carrying the credential — and the
+TTL above means a forgotten one expires rather than lingering.
+
 Whether anything more is needed depends on
 `services.hyperhive.deploy.bao.seal`: