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

nix/host-modules/swarm-secret-publisher.nix

@@ -64,10 +64,13 @@ let
   #
   # The ids come from `swarm.*`, which is identical on every host — that is what
   # lets this host name a service's client while running none of them, and it is
-  # the same read the service's own module registers the client with. A swarm
-  # that runs no Grafana mints no secret for it, so its entry skips below rather
-  # than needing a condition here.
-  serviceClientIds = [ hyperhiveCfg.swarm.grafana.oidc.clientId ];
+  # the same read each service's own module registers its client with. A swarm
+  # that runs no Grafana, or no collector, mints no secret for the one it lacks,
+  # so its entry skips below rather than needing a condition here.
+  serviceClientIds = [
+    hyperhiveCfg.swarm.grafana.oidc.clientId
+    hyperhiveCfg.swarm.otel.clientId
+  ];
 in
 {
   options.services.hyperhive.deploy.swarm-secret-publisher = {
@@ -92,10 +95,11 @@ in
         identity's job (see `baoClientCertFile`), not this option's.
 
         Turning it off leaves every hive but this one without its agents'
-        credential, and the swarm's Grafana without any login at all — its
-        secret has exactly one route and this is the producer's end of it. So
-        the honest reason to set it false is a deployment delivering those
-        secrets by some other mechanism it owns.
+        credential, the swarm's Grafana without any login at all, and its
+        collector pushing unauthenticated — each secret has exactly one route
+        and this is the producer's end of it. So the honest reason to set it
+        false is a deployment delivering those secrets by some other
+        mechanism it owns.
       '';
     };