hive-forge: the controller-token mint writes straight to the store, and the on-disk token goes

`forgejo-swarm-controller-account`, in the forge's container, now puts
the swarm-controller's forge token into the swarm secret store itself,
under the forge publisher's leaf. The container already receives that
leaf as nspawn system credentials for its journal forwarder; the mint
loads the same three. The token reaches bao on stdin (`value=-`) and
the forge's API through a header file, never as an argument, and never
touches disk.

The mint's guard is a marker holding the published token's name, at
/var/lib/forgejo/swarm-controller-token-name, written last: after the
put, and after every other `swarm-controller-boot-*` token of the
account is revoked through forgejo's admin API, authenticated as the
new token. So a put that failed, or a marker lost while the store kept
an older token, leaves no live token behind once a mint completes. The
mint logs in to the store and checks that the account is a site admin
before it mints, so a store that is down or an account the admin API
would refuse mints nothing on each retry. Failures retry under
store-retry; forgejo does not wait for the mint. No bao read and no
grant change: the forge publisher keeps create/update on the token.

Removed: the host's `swarm-bao-forge-publisher` service and path unit,
which read the token file through the container's root, and their
entries in the store and policy ordering glue. The forge publisher's
policy unit stays; `swarm-bao-forge-oidc` still uses the leaf.

On deploy, an existing forge host has no marker, so the mint runs once:
it mints a new token, publishes it, revokes the old one, and deletes
the old /var/lib/forgejo/swarm-controller-token. The controller's next
forge call gets a 401, re-reads the store and carries on.

nix/host-modules/swarm-bao.nix

@@ -1107,9 +1107,10 @@ let
     }
   ];
 
-  # The forge host's one store identity. `swarm-bao-forge-publisher` writes
-  # the controller's forge token under it, the one writer of that path and
-  # write-only: it copies a file in and never reads one back.
+  # The forge host's one store identity. The forge's
+  # `forgejo-swarm-controller-account`, in its container, writes the
+  # controller's forge token under it, the one writer of that path and
+  # write-only: it puts the token it mints and never reads one back.
   # `swarm-bao-forge-oidc` reads the forge's own OIDC client secret, and the
   # journal forwarder in its container its own, those two leaves and no other
   # service's.
@@ -2016,8 +2017,9 @@ in
       default = "swarm-forge-publisher";
       description = ''
         Subject the store's `swarm-forge-publisher` cert-auth role accepts: the
-        forge host's one store identity, presented by `swarm-bao-forge-publisher`,
-        which publishes the swarm-controller's forge token, and by
+        forge host's one store identity, presented by
+        `forgejo-swarm-controller-account` in the forge's container, which
+        mints and publishes the swarm-controller's forge token, by
         `swarm-bao-forge-oidc`, which fetches the forge's OIDC client secret,
         and by the journal forwarder in the forge's container. Its grant is
         three paths: `swarm/controller/swarm-controller/forge/token`, write
@@ -2342,9 +2344,10 @@ in
       default = null;
       example = "/var/lib/swarm-bao-pki/forge-publisher.pem";
       description = ''
-        Certificate the forge's host presents to the store, both to publish the
-        swarm-controller's forge token and to fetch the forge's OIDC client
-        secret. Its subject must be
+        Certificate the forge's host presents to the store, to fetch the
+        forge's OIDC client secret, and that the forge's container presents to
+        publish the swarm-controller's forge token and to fetch its journal
+        forwarder's secret. Its subject must be
         {option}`services.hyperhive.deploy.bao.forgePublisherCommonName`.
 
         ./glue-bao-tls.nix points it at the leaf it mints on the store's host.