docs(swarm): point sso.md's secrets section at secrets.md instead of restating it

docs/swarm/sso.md

@@ -91,22 +91,12 @@ an attribute edit can invalidate a login by accident.
 ## What secrets exist, and where each one lives
 
 Every secret in the swarm, with its generator and its path, is tabulated
-in one place: [`secrets.md`](secrets.md). The rows relevant here are
-authelia's own keys (session, JWT, storage-encryption, OIDC HMAC, OIDC
-issuer) plus the two halves of each client secret.
-
-What matters for this page is the shape rather than the paths. Authelia's
-own keys are generated **in-container**, because nothing outside that
-container ever reads them — that is the test worth applying to any secret
-added here. The plaintext half of a client secret is the one that fails
-it: its reader lives in a different container, and that is the entire
-reason a delivery step exists.
-
-**None of it is ever written into a nix expression.** authelia's
-`settings` are rendered into the nix store, which is world-readable and
-permanent, so the client digest reaches authelia through `settingsFiles`
-(merged at runtime) and every other secret through a `*File` option
-carrying a path rather than a value.
+in one place: [`secrets.md`](secrets.md), including authelia's own keys
+(session, JWT, storage-encryption, OIDC HMAC, OIDC issuer) and the two
+halves of each client secret. That page's two rules — a secret is always
+a path, never a value, and the generator and the reader are usually in
+different containers — are why the client secret's plaintext half needs
+the delivery step below and the rest of authelia's keys don't.
 
 ## Getting the plaintext to the relying party