swarm-otel: deliver the OIDC client secret through the secret store

The swarm collector's OIDC client secret only existed where authelia
did: `swarm-otel-oidc-secret.service` copied the minted plaintext out
of authelia's container tree, reachable only because the two share a
host's network namespace. A swarm that placed authelia elsewhere
delivered nothing, and the option's own description said so —
"a deployment that places authelia elsewhere points this at a file it
delivers itself." Same gap as #3853 and #4234, and this is the
swarm-otel twin of #4234's fix for Grafana.

Mirrors PR #4361 (Grafana) almost exactly:

- `swarm-bao-otel-oidc.service` reads
  `swarm/services/<client-id>/oidc/client` out of the store, in every
  deployment, replacing the co-located copy unit outright — one
  delivery route, not two, per the ruling that landed under #4234.
- Client registration moved out of `swarm-otel.nix`'s own `config`
  block (gated on this host running the collector) into
  `glue-swarm-otel-oidc-client.nix` (gated on this host running
  authelia), the same split `glue-grafana-oidc-client.nix` made. It
  was broken the same way: a split deployment registered the client
  nowhere at all, so authelia never minted a secret for the publisher
  to send on.
- The publisher's `services` prefix (write grant in `swarm-bao.nix`,
  hive read grant in `policy::render`) already covers any service's
  path — nothing to add there. `swarm-secret-publisher.nix` only grew
  `serviceClientIds` by one entry.

One judgement call, stated rather than buried: the store-reading unit
renders only where this host holds a client identity
(`deploy.bao.clientCertFile`/`clientKeyFile`), rather than asserting
it the way `swarm-grafana.nix` does. Grafana's local login form is
disabled unconditionally, so a Grafana with no OIDC secret has no way
in at all — that earns a hard refusal. This collector without a
credential still receives every hive's telemetry; only its own pushes
to the stores go out unauthenticated and get refused there, an
already-supported degrade the module's own `haveCollectorSecret` flag
named before this change. So the reading unit follows the shape
`glue-matrix-bao-token.nix` and `glue-queue-agent-credential.nix` use
for their own optional readers: no unit when the identity is absent,
not a build refusal.

Fixtures mirror #4361's: `otelBaoWithAuthelia`/`otelBaoRemoteAuthelia`
are the positive pair (co-located and split, both reading through the
store), `otelNoIdentity` is the negative — no reading unit, no
assertion firing, `clientSecretFile` left null.

Refs #4258

docs/trust-boundary/security.md

@@ -66,16 +66,17 @@ _own_ entry under the hive namespace, which names the hive asking and so widens
 nothing between them, and every **swarm service's** OIDC client secret.
 
 That third prefix has the same shape of reason as the first, and the same honest
-cost. A swarm service (Grafana is the one there today) registers **one** client
-for the whole swarm, so its credential's path names the service and never the
-host — and which hive runs a given service is a `deploy.*` fact, per-host by
-definition, so nothing swarm-wide exists to scope the grant to. The host running
-such a service has no store identity of its own either; it reads with the
-certificate of the hive it is. **Any hive can therefore read any swarm service's
-client secret**, which is worth what it buys: every swarm service gets its
-credential the same way from anywhere, instead of only where the identity
-provider happens to sit. Giving such a service its own store identity is what
-would remove this rather than re-scope it.
+cost. A swarm service (Grafana and the swarm collector are the two there today)
+registers **one** client for the whole swarm, so its credential's path names
+the service and never the host — and which hive runs a given service is a
+`deploy.*` fact, per-host by definition, so nothing swarm-wide exists to scope
+the grant to. The host running such a service has no store identity of its own
+either; it reads with the certificate of the hive it is. **Any hive can
+therefore read any swarm service's client secret**, which is worth what it
+buys: every swarm service gets its credential the same way from anywhere,
+instead of only where the identity provider happens to sit. Giving such a
+service its own store identity is what would remove this rather than re-scope
+it.
 
 **A tracked follow-up** narrows this, with the two candidate directions: scope
 the grant per hive (and pay for the re-emission), or give each agent container