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.

swarm-queue-client/src/stored_secret.rs

@@ -1,8 +1,8 @@
 //! A client secret held in memory and read again from where it is kept when
 //! the `IdP` refuses it.
 //!
-//! The secret can change under a running process: authelia's host
-//! re-publishes it when it is re-minted. A refusal asks for a re-read
+//! The secret can change under a running process: the publisher in authelia's
+//! container re-publishes it when it is re-minted. A refusal asks for a re-read
 //! ([`StoredSecret::after_refusal`]); when the read lands a different secret,
 //! the caller tries once more with it. One re-read runs at a time, and a
 //! refusal while one is running waits for it rather than starting another.