swarm CA: describe the store's pki root as the only anchor in docs and comments

The docs, option descriptions and comments that named the swarm root, the
swarm CA or the hive CA as an existing trust anchor now name the secret
store's pki root or the trust bundle that holds it:

- docs/swarm/README.md, secrets.md, bao.md
- deploy.bao.clientCaFile's and gateway.verifiedProxyTo's descriptions
- comments in hive-c0re/src/meta.rs, hive-agent/src/swarm_queue.rs,
  swarm-logs/src/auth.rs, swarm-controller/src/vcs_metrics.rs,
  hive-forge, swarm-authelia, swarm-ci-runner, glue-bao-tls, swarm-bao,
  swarm-grafana, swarm-otel, otel, hive-c0re, lib/hive-ca-trust.nix,
  hive-forge/Cargo.toml and the flake-update workflow

Nothing behaves differently: every edit is a nix, Rust or TOML comment, an
option description, or a test assertion message. The Rust edits change the
workspace source, which this PR already rebuilds for hivectl.

Refs #4588

docs/swarm/README.md

@@ -397,9 +397,10 @@ hive's domain. `swarm.name` names the group; `hiveName` names this hive.
 The env-var chain and `qualify()` / `qualified_label()` semantics:
 [`conventions.md`](../process/conventions.md) § Hive identity.
 
-Trust inside a swarm comes from the swarm root ([`ca.md`](ca.md)): every hive
-chains to it. Trusting a hive whose root this swarm doesn't own — another
-swarm's — has no mechanism.
+Trust inside a swarm comes from the secret store's `pki` root
+([`ca.md`](ca.md)): every hive's gateway leaf chains to it. Trusting a
+hive whose root this swarm doesn't own — another swarm's — has no
+mechanism.
 
 ### What the directory feeds
 
@@ -415,7 +416,7 @@ swarm's — has no mechanism.
 
    ⚠️ On a hive with self-signed gateway certificates, the container
    also trusts this hive's `trust-bundle.pem`, bound in at runtime and
-   added to the public CAs; it ends at the swarm root, so a peer whose
+   added to the public CAs; it holds the store's `pki` root, so a peer whose
    certificate chains to the same root validates. A peer outside this
    swarm's root needs a CA-issued certificate (ACME). Federation firewall
    and TLS requirements: [`integrations/matrix.md`](../integrations/matrix.md).

docs/swarm/bao.md

@@ -106,7 +106,7 @@ itself, plus a pair for every principal it runs — see
 The operator issues those leaves out of band; they're the credentials the
 store can't hand you, being what opens it.
 
-⚠️ Not the gateway's HTTPS certificates and not the hive CA — this is **mTLS
+⚠️ Not the gateway's HTTPS certificates and not the store's `pki` root — this is **mTLS
 between services and the store**, a separate trust domain, because a store
 that took its identity from an authority it itself distributes could never
 come up before that authority.

docs/swarm/secrets.md

@@ -273,8 +273,8 @@ client secret to stand in.
 ⚠️ **Service↔store mTLS is its own trust domain.** You can't fetch a
 credential you must already hold to authenticate from the thing it
 authenticates you to, so the store's identity can't come from an authority the store
-distributes — which excludes the hive CA and the swarm CA both, and has nothing
-to do with the gateway's HTTPS certificates either way. `glue-bao-tls.nix`
+distributes — which excludes the store's `pki` root, and has nothing to do
+with the gateway's HTTPS certificates either way. `glue-bao-tls.nix`
 mints a CA that signs a fixed, short list of leaves — the store's server
 certificate, the hive's own reader certificate, and one per service principal —
 and distributes nothing. A deployment with a real