swarm CA: retire the host-held root CA, the store holds the only anchor

The secret store's pki root issues every hive's gateway leaf and the
swarm's service names, so the root swarm-ca.service generated on the
host anchors nothing and its key is a secret outside the store.

- swarm-ca.nix is gone: swarm-ca.service, root.pem and root-key.pem,
  and the swarm.ca.{autoConfigure,stateDir,validityDays} options. A
  definition of any of them fails evaluation with a removal message
  (swarm-ca-removed.nix), and a tmpfiles rule deletes /var/lib/swarm-ca
  on every host. singleHostSwarm no longer sets a swarm.* option.
- hive-tls-ca drops the $root slot: trust-bundle.pem holds the store's
  pki root and a hive CA's public ca.pem/ca-previous.pem only.
- hivectl peer-config no longer prints the scp line for the swarm root;
  the store's pki root is the one step.
- The gateway's cert import no longer stands a hive leaf or a throwaway
  in for a missing swarm-services leaf where it Requires= the issuing
  unit: it fails, naming swarm-services-cert.service. The stand-in stays
  where the gateway does not wait (no swarm name, or the store's UI
  only, whose passthrough must start with the store sealed).

Comments and docs that named swarm-ca.nix, swarm.ca.* or the host root
now name the store's pki root.

Refs #4588

nix/host-modules/swarm.nix

@@ -72,13 +72,13 @@ let
   # `serviceDomains` below is this set sorted + deduplicated.
   #
   # ⚠️ These are NOT required to be under `swarm.domain`. An earlier
-  # revision asserted that, reasoning that the services sub-CA is
-  # constrained to the swarm's tree — but the sub-CA is constrained to
-  # the **configured names** (./swarm-ca.nix) and the swarm root carries
-  # no name constraints at all, so any configured name is issuable. The
-  # assertion encoded an intended shape, not a property of the code, and
-  # it rejected the supported migration path: a hive pinning its old
-  # `forge.<hive domain>` while joining a swarm at a different apex.
+  # revision asserted that, reasoning that the services issuer is
+  # constrained to the swarm's tree — but the store's `swarm-services`
+  # role admits exactly the **configured names** (./swarm-bao.nix), so any
+  # configured name is issuable. The assertion encoded an intended shape,
+  # not a property of the code, and it rejected the supported migration
+  # path: a hive pinning its old `forge.<hive domain>` while joining a swarm
+  # at a different apex.
   #
   # Every name is listed whether or not this host runs the service: the
   # store's issuing role is built from this list on the store's host and
@@ -226,9 +226,9 @@ in
               visible = false;
               internal = true;
               description = ''
-                Removed. Trust inside a swarm comes from the swarm root CA
-                (`services.hyperhive.swarm.ca`, docs/swarm/ca.md), which
-                replaces per-hive leaf pinning entirely.
+                Removed. Trust inside a swarm comes from the secret store's
+                pki root (docs/swarm/ca.md), which replaces per-hive leaf
+                pinning entirely.
               '';
             };
           };
@@ -369,9 +369,9 @@ in
           existed to serve — nothing else ever consumed it.
 
           There is no replacement, and none is needed for a hive inside
-          this swarm: trust comes from the swarm root CA
-          (services.hyperhive.swarm.ca — see docs/swarm/ca.md), which
-          every hive chains to, so one anchor replaces per-hive pinning.
+          this swarm: trust comes from the secret store's pki root (see
+          docs/swarm/ca.md), which every hive chains to, so one anchor
+          replaces per-hive pinning.
           What that genuinely drops is trusting a hive whose root this
           swarm does NOT own — another swarm's, or one keeping its own
           CA. That is a cross-swarm problem and wants a mechanism