hive-tls: the gateway leaf uses the services-issuer identity, not a hive's

swarm-services-cert issues the swarm-services leaf a self-signed gateway
serves, and on a host fronting no swarm name fetches the store's pki root.
It is gated on the gateway, not on a hive, yet its leaf pair was named
under deploy.hive-controller.tls and defaulted from the hive reader's cert
directory, and the root fetch presented the hive's own identity. A gateway
host with no hive had no such identity, so that branch was red by
construction.

- The pair moves to deploy.bao.servicesIssuerClient{Cert,Key}File, beside
  the store's other host-unit readers, and glue-bao-tls.nix defaults it on
  the store's host from the leaf it already mints. The old
  deploy.hive-controller.tls.baoClient{Cert,Key}File paths are
  mkRenamedOptionModule aliases. glue-services-issuer-bao-identity.nix,
  which derived the default from deploy.bao.clientCertFile, is gone.
- The no-swarm-name root fetch presents the services-issuer pair. The hive
  identity is now only hive-tls-resign's.
- A self-signed gateway with no pair fails evaluation, naming both options.
  A pair named but unreadable still fails the unit, naming the paths.

Refs #4921

docs/swarm/ca.md

@@ -39,11 +39,10 @@ from the store's own client CA, with the subject
   and set both options, before the host's next deploy.
 
 Without it, `hive-tls-resign.service` fails with a message naming both
-options, and so does `swarm-services-cert.service` on a hive fronting no
-swarm name. The unit checks the identity before the leaf, so it fails even while a
+options. The unit checks the identity before the leaf, so it fails even while a
 valid leaf keeps the gateway up. The identity is the hive's alone:
-it issues this hive's leaf and fetches the store's root, and it's never the
-identity a swarm service uses.
+it issues this hive's leaf and nothing else, and it's never the identity a
+swarm service uses.
 
 **When it issues.** The unit runs at boot, on every deploy, and from
 `hive-tls-resign.timer` once a day. It asks the store for a new leaf when
@@ -108,12 +107,33 @@ domain, so it can't cover them.
 
 The secret store's `pki` mount issues them a leaf of their own, through its
 `swarm-services` role. `swarm-services-cert.service` logs in with
-this host's services-issuer certificate, calls
+the services-issuer identity, calls
 `pki/issue/swarm-services`, and writes the result to
 `/var/lib/hive-tls/swarm-services.pem` — the path the gateway already
-copies from. Every hive does this with its own identity, so the store's
-role, not a key on the hive, decides whether a hive can serve its swarm's
-names.
+copies from. The store's role, not a key on the host, decides which names a
+gateway can serve.
+
+**Every gateway that serves the self-signed leaf needs the services-issuer
+identity**, whether or not a hive runs on its host. It's a client certificate
+from the store's own client CA, with the subject
+`deploy.bao.servicesIssuerCommonName` (`swarm-services-issuer` by default),
+and it's named by `services.hyperhive.deploy.bao.servicesIssuerClientCertFile`
+and `servicesIssuerClientKeyFile`. Its policy may issue from
+`pki/issue/swarm-services` and nothing else, and it's the same certificate on
+every gateway host:
+
+- On the host running the store, `swarm-bao-pki.service` mints it at
+  `/var/lib/swarm-bao-pki/services-issuer.pem` and the two options default to
+  it.
+- On every other gateway host, copy `services-issuer.pem` and
+  `services-issuer-key.pem` from the store's host and set both options.
+
+A host whose gateway serves the self-signed leaf without both options set
+fails evaluation, naming them. One that names files it can't read fails
+`swarm-services-cert.service`, naming the paths. The old spellings,
+`deploy.hive-controller.tls.baoClientCertFile` and `baoClientKeyFile`, are
+renames of these two: a config that still sets them evaluates with a warning
+naming both paths.
 
 `services.hyperhive.swarm.serviceDomains`, every swarm service name and the
 same list on every host, populates the role's
@@ -123,14 +143,12 @@ it. A host's own SANs are narrower still: it asks only for the names it
 fronts a vhost for (`swarm.localServiceDomains`), so the key on one
 gateway can't serve a swarm service that runs behind another.
 
-**The root's public certificate is a file, on every hive:**
+**The root's public certificate is a file, on every self-signed gateway host:**
 `/var/lib/hive-tls/swarm-services-root.pem` (0644), written beside the
-leaf it signed and folded into `trust-bundle.pem`. A hive fronting no
+leaf it signed and folded into `trust-bundle.pem`. A host fronting no
 swarm name asks for no services leaf and reads the root alone, from the store's
-`pki/ca/pem`, presenting its own store identity
-(`deploy.hive-controller.tls.baoHiveIdentityCertFile` /
-`baoHiveIdentityKeyFile`) for the handshake. Every hive must hold one:
-without it, or with either file absent,
+`pki/ca/pem`, presenting the services-issuer identity for the handshake
+without logging in with it. With either file absent,
 `swarm-services-cert.service` fails with a message naming both options.
 On the host running
 the store it's also at