swarm-bao: refuse a remote reader that named seven of the eight leaves

The four-way client-cert split gives each store reader its own leaf, and
three of the four readers render only where their own leaf exists. On a
host that mints its own PKI glue-bao-tls.nix defaults all eight, so there
is nothing to do; on a hand-configured remote-store hive, omitting one
pair used to mean that unit silently did not render — a privilege-
narrowing unit absent from a green build, with the missing unit as the
only evidence.

Each of the three now asserts its own pair, shaped after
swarm-grafana.nix's haveClientIdentity assertion and named to the pair it
needs. What differs from Grafana's is the gate: these fire only where the
host demonstrably reads the store (it holds deploy.bao.clientCertFile and
clientKeyFile) and the consumer is on. A host with no store identity is
the supported no-store deployment and still evaluates; the collector's
no-secret degrade is untouched, because that host holds no clientCertFile
either.

Also rewords three passive-voice sentences in docs/swarm/secrets.md that
vale flagged, and documents what the refusal costs and where it stays
silent.

docs/swarm/secrets.md

@@ -250,7 +250,7 @@ round trip cheaper and costs a second delivery unit, a second way for the file
 to be wrong, and a gate deciding between them — and the gate is the expensive
 part, because whatever it's wrong about is an outage nobody can read. The store
 exists so the only secrets a host holds out of band are **certificates**, and
-everything else is read with them.
+a host reads everything else with them.
 
 Two things follow, and `swarm-grafana.nix` asserts both rather than degrading:
 running Grafana requires `swarm.authelia.url` (this module disables its local
@@ -319,7 +319,7 @@ internal CA deletes that file and names its own paths in
 `deploy.bao.serverCertFile` / `clientCaFile`; the store itself has no opinion.
 A hive that reads from a store on **another** machine names the reader's half —
 `clientCertFile`, `clientKeyFile`, `serverCaFile` — and places that leaf by hand,
-plus one leaf per principal it runs (the options are listed below). Those are the
+plus one leaf per principal it runs (the table below names the options). Those are the
 credentials that can't come out of the store, being what opens it; everything
 else a hive needs does.
 
@@ -336,20 +336,55 @@ each and each holds a leaf, a role and a policy of its own:
 | `swarm-bao-grafana-oidc` | `grafanaOidcClientCertFile` / `grafanaOidcClientKeyFile` | `swarm/services/<grafana client id>/oidc/client`   |
 | `swarm-bao-otel-oidc`    | `otelOidcClientCertFile` / `otelOidcClientKeyFile`       | `swarm/services/<collector client id>/oidc/client` |
 
-The first two are written **per hive**, because the path they read carries a hive
+The first two exist **per hive**, because the path they read carries a hive
 name and every hive runs its own reader. Their subjects are
 `<deploy.bao.matrixTokenCommonNamePrefix>-<hive>` and
 `<deploy.bao.queueAgentCommonNamePrefix>-<hive>`; `swarm.nix` reserves both
-composed spellings as hive names, so a hive can't be named into another hive's
+composed spellings as hive names, so nobody can name a hive into another hive's
 role. The other two read 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` and `deploy.bao.otelOidcCommonName`.
 
 On a host that mints its own PKI, `glue-bao-tls.nix` signs all four and defaults
-all eight options, and there is nothing to do. Elsewhere each leaf is issued from
-that CA out of band and named here — one file per principal rather than one file
+all eight options, and there is nothing to do. Elsewhere you issue each leaf from
+that CA out of band and name it here — one file per principal rather than one file
 shared by four, which is the whole of what this buys.
 
+Forgetting one of the eight elsewhere isn't a quiet degrade. Three of the four
+readers used to render only where their leaf existed, so a hand-configured
+remote-store hive that named the hive's own `clientCertFile` and missed a
+principal's pair just lost that unit; `swarm-grafana.nix` was alone in refusing
+the build. All four now refuse it, each naming its own option pair — see
+[what a missing leaf costs](#what-a-missing-leaf-costs) below.
+
+### What a missing leaf costs
+
+Each of the four modules asserts its own pair, on the same condition: **this host
+already reads the store** — it holds `deploy.bao.clientCertFile` and
+`clientKeyFile` — **and the consumer is on, and this principal's pair is null**.
+The refusal names the two options, so an operator acts on the message without
+opening the nix.
+
+That condition fires on exactly one shape, the hand-configured remote-store hive
+that named seven of the eight. It stays silent everywhere else, and each half of
+that matters on its own:
+
+- **A host with no store identity at all** holds no `clientCertFile` either, so
+  the first clause is false. That's the supported no-store deployment, and also
+  the one an operator passes through while bringing a hive up — neither should
+  fail to evaluate.
+- **A host that runs the store** gets all eight from `glue-bao-tls.nix` as
+  defaults, so the third clause is false. Nothing to set, nothing to refuse.
+- **A consumer that's off** — no homeserver, no collector, no Grafana — has no
+  unit to skip, so the second clause is false. Only the queue-credential reader
+  has no toggle of its own to check: every hive runs one for its own agents, so
+  reading the store at all is what asks for it.
+
+The collector keeps a separate degrade underneath this, unchanged: a host with no
+store identity runs a collector with no OIDC client secret and still receives
+telemetry. The assertion doesn't touch that shape, because that host has no
+`clientCertFile` either.
+
 ## How a reader reaches the store
 
 Every reader dials the same URL — `https://bao.<swarm domain>:<port>` — and on