swarm-authelia: run the secret publisher and a journal forwarder inside the container

swarm-secret-publish and its path unit now run inside authelia's container,
beside the mint, and read each client secret at the path authelia writes it.
The host unit and host path unit, which read the secrets through the
container's root on the host, are gone, and so is
deploy.authelia.hostClientSecretDir, which only they read. The publisher keeps
its store identity, the secret-publisher leaf. The host hands the leaf and the
store's CA into the container as nspawn system credentials, and the unit loads
them; where this host mints the leaf, the container waits for swarm-bao-pki.
Authelia does not wait for the publisher, which retries every 30 seconds while
the store is down.

The container also runs the journal forwarder the other service containers
run, pushing to a receiver of its own on the swarm collector (serviceProducers
swarm-authelia) as a new machine OIDC client (swarm.authelia.otel.clientId)
that authelia registers for itself and the publisher carries to the store. The
fetch unit reads it back under the publisher's leaf, also handed to it as a
system credential, so the swarm-secret-publisher policy gains read on that one
leaf; its stanza keeps create and update, which the exact path would otherwise
take from the services/* prefix. Without the leaf the forwarder is off.

The container drops --link-journal=host, and the host collector stops reading
it. The services' "nothing at <path>" errors name the publisher in authelia's
container.

docs/swarm/services.md

@@ -127,6 +127,14 @@ The swarm collector scrapes authelia's own metrics at
 container. The gateway admits only the collector's OAuth2 client there;
 any other session gets `deny`.
 
+The container also runs `swarm-secret-publish`, which copies the client
+secrets authelia mints into the swarm secret store under the secret
+publisher's own store leaf, handed in as a system credential; see
+[`secrets.md`](secrets.md). Authelia doesn't wait for it, so the IdP comes up
+while the store is down, and the publisher retries every 30 seconds. The
+container's journal forwarder reads its client secret back from the store
+under the same leaf, and is off where the container has none.
+
 See [`sso.md`](sso.md) for bootstrapping the first user and the OIDC
 relying-party flow, and [`secrets.md`](secrets.md) for where authelia
 generates and reads each of its keys.
@@ -301,17 +309,17 @@ gateway either way.
 
 The `swarm-bao`, `swarm-nats`, `swarm-builder`, `swarm-claude-login`,
 `swarm-review-classifier`, `swarm-ci-runner`, `swarm-grafana`,
-`swarm-victorialogs`, `swarm-victoriametrics`, `hive-forge` and `hive-matrix`
-containers each run a collector of their own that forwards the container's
+`swarm-victorialogs`, `swarm-victoriametrics`, `swarm-authelia`, `hive-forge`
+and `hive-matrix` containers each run a collector of their own that forwards the container's
 journal here, on a route and receiver per service
 (`https://<swarm.otel.domain>/<container>/`), authenticated as an OIDC client
 of that service's. The queue, builder, login minter and classifier reuse the
 service's own client; the store, CI runner, Grafana, log store, metrics store,
-forge and homeserver have a forwarder client of their own
+authelia, forge and homeserver have a forwarder client of their own
 (`swarm.<service>.otel.clientId`). Their records carry `service.name` (`bao`,
 `nats`, `builder`, `claude-login`, `review-classifier`, `ci-runner`,
-`grafana`, `victorialogs`, `victoriametrics`, `forgejo`, `tuwunel`) and no
-`hive` label. The forwarder of all but the store's is
+`grafana`, `victorialogs`, `victoriametrics`, `authelia`, `forgejo`,
+`tuwunel`) and no `hive` label. The forwarder of all but the store's is
 `nix/container-modules/swarm-journal-forwarder.nix`.
 
 **Both store exporters are unconditional**, and `deploy.victoriametrics.enable`