swarm: mint, publish and login-verify an agent's store identity at create

`swarm/agents/<agent>/bao-mtls` did not exist, and neither did any
per-agent identity at the secret store: `policy::agent_object_name`,
`render_agent` and `render_agent_with_queue` had been written and never
called outside their own tests. An agent's only "per-agent" secret today
is read under the HIVE's certificate, through a wide grant on
`swarm/agents/*` — so "per-agent" was presentational.

The swarm now mints the certificate, so no hive ever needs the capability
to mint one. `swarm-controller` is the service that does it: it already
logs in to the store, and its existing grant already covers exactly the
three objects written here (`create/update` on
`secret/data/swarm/agents/*`, `sys/policies/acl/hive-*` and
`auth/cert/certs/hive-*`). No new bao grant, and nothing co-located — a
cert-auth role pins its authority by value, per role, so the controller
issues from its own CA on its own host and pins that CA in the role it
writes. No existing role changes.

The mint node does not report success on a write. After publishing it
connects again, with the leaf it just issued and under the role it just
wrote, and reads the path back — so the policy, the role, the common name
and the leaf are exercised in production on every agent creation. A
certificate this code mints that the role this code writes will not accept
turns the job node red at creation time instead of surfacing later as an
agent container that cannot start.

`TriggerDeploy` gains an `after_any` edge on the mint, not `after_ok`: a
hive cannot pass down a certificate the swarm has not published, but a
host with no authority configured must still create agents exactly as it
does today.

The private key is generated in memory and never written to disk on the
controller — `SecretStore::connect_with_identity` takes the PEM the minter
is already holding, so nothing is written out purely to be logged in with.

Refs #4137

swarm-secret-client/src/client.rs

@@ -112,7 +112,37 @@ impl SecretStore {
         let mut pem = read_file(ENV_CLIENT_CERT, &settings.cert_path)?;
         pem.push(b'\n');
         pem.extend_from_slice(&read_file(ENV_CLIENT_KEY, &settings.key_path)?);
-        let identity = reqwest::Identity::from_pem(&pem).map_err(Error::Tls)?;
+        Self::connect_with_identity(settings, &pem, cert_role, cert_mount).await
+    }
+
+    /// Log in at the store `settings` names, presenting an identity the caller
+    /// is already holding rather than one named by the environment.
+    ///
+    /// `identity_pem` is the certificate and its private key concatenated into
+    /// one PEM blob — the shape [`reqwest::Identity::from_pem`] takes, and the
+    /// shape [`SecretStore::connect`] builds out of the two files
+    /// [`ENV_CLIENT_CERT`] and [`ENV_CLIENT_KEY`] name. Only the address and
+    /// the CA are read out of `settings` here; its two identity paths are not
+    /// touched.
+    ///
+    /// This is what a **minter** needs. A process that has just issued a leaf
+    /// holds the bytes, and the safest place for a freshly minted private key
+    /// is the memory it was generated in: writing it to a file purely so that
+    /// a `Settings` could name it would put a key on disk for no other reason
+    /// than to log in with it once.
+    ///
+    /// # Errors
+    /// [`Error::Tls`] when `identity_pem` is not a usable certificate/key
+    /// pair, [`Error::Settings`] when the address will not parse, and
+    /// [`Error::Vault`] when the store refuses the login — which is what a
+    /// certificate no cert-auth role accepts looks like from here.
+    pub async fn connect_with_identity(
+        settings: &Settings,
+        identity_pem: &[u8],
+        cert_role: &str,
+        cert_mount: &str,
+    ) -> Result<Self, Error> {
+        let identity = reqwest::Identity::from_pem(identity_pem).map_err(Error::Tls)?;
 
         let mut builder = VaultClientSettingsBuilder::default();
         builder