hive-c0re: deliver an agent's credential from the store to its state dir

mara on #4015: "not merging code without callers", and on the same PR
"see issue, we decided what the first thing should be". #3726 decided it:
the controller writes a token to the store and tells the hive; the hive
reads it back and writes /agents/<agent>/state/matrix-token-<account> at
0600, where matrix.nix's existing systemd.paths glob re-fires the daemon.
So this is the hive half of that, and the library's first caller.

The notice names a credential and never carries one, and deploy_subject's
own doc is why: the auth-callout responder scopes publish and leaves sub
unrestricted, so a hive that wanted another's messages could subscribe to
them. A secret in that payload would be readable swarm-wide. The value is
read from the store under the reading hive's own certificate, where the
store's policy is what actually scopes it.

Two boundaries guard the two addresses, and they are not the same check.
`path::matrix_account` guards the address in the store. `Ident` guards the
address on disk -- `agent_state_dir` takes one, so an unvalidated name off
the queue cannot reach a directory. I had written the first and assumed it
covered both; the compiler refused the `&str` and was right. `token_path`
now takes the newtype so a call site cannot forget.

The write is atomic because the path-watcher fires on the file appearing:
written in place it would be visible while partial, and the daemon would
read a truncated credential exactly once, which is the hardest possible
failure to reproduce. The temp name is dot-prefixed so it cannot match the
`matrix-token*` glob on its way past.

The publish grant is here because without it the failure is invisible.
policy.rs already says why for its siblings: a refused publish reaches the
client as a timeout, so the symptom is a hive that never receives a
credential with nothing in either log naming a permission. Two tests: the
controller may publish, a hive may not -- its own subject included. A
forged notice leaks nothing, but it would make a hive fetch and overwrite
a token file for a name the forger chose.

Refs #3726

hive-c0re/src/swarm_status.rs

@@ -198,7 +198,24 @@ async fn drain_swarm_events(
             return;
         }
     };
-    tracing::info!(%subject, %deploy_subject, "swarm events: listening");
+    // Also this hive's own, and for a second reason on top of the deploy
+    // subject's: the payload names an agent in *this* hive's state dir, so a
+    // notice for another hive is not merely noise, it is unactionable here.
+    let credential_subject = swarm_queue_client::credential_subject(&hive);
+    let mut credential_sub = match client.subscribe(credential_subject.clone()).await {
+        Ok(sub) => sub,
+        Err(e) => {
+            tracing::warn!(
+                subject = %credential_subject, error = %e,
+                "swarm events: subscribe failed; this hive will not hear credential notices"
+            );
+            return;
+        }
+    };
+    tracing::info!(
+        %subject, %deploy_subject, %credential_subject,
+        "swarm events: listening"
+    );
 
     loop {
         tokio::select! {
@@ -223,6 +240,13 @@ async fn drain_swarm_events(
                 };
                 handle_deploy_request(&coord, &msg.payload).await;
             }
+            msg = credential_sub.next() => {
+                let Some(msg) = msg else {
+                    tracing::warn!(subject = %credential_subject, "swarm events: credential subscription closed");
+                    return;
+                };
+                handle_credential_notice(&hive, &msg.payload).await;
+            }
             _ = shutdown.changed() => {
                 tracing::info!("swarm events: shutdown signal received");
                 return;
@@ -236,6 +260,39 @@ async fn drain_swarm_events(
 ///
 /// A payload that will not decode is worth a `warn`: the controller and this
 /// end share one type, so a decode failure means they disagree about it.
+/// Deliver the credential a [`swarm_queue_client::CredentialNotice`] names.
+///
+/// `hive` doubles as the cert-auth role this hive logs into the store as:
+/// `glue-bao-tls.nix` mints the client certificate with the hive name as its
+/// CN, and a bao cert role matches on CN — so the two share a name by
+/// construction rather than by convention.
+///
+/// ⚠️ Nothing here can log the secret, and that is structural rather than
+/// careful: the notice carries only names, and `deliver` writes the value
+/// without returning it.
+async fn handle_credential_notice(hive: &str, payload: &[u8]) {
+    let notice: swarm_queue_client::CredentialNotice = match serde_json::from_slice(payload) {
+        Ok(notice) => notice,
+        Err(e) => {
+            tracing::warn!(error = %e, "swarm events: undecodable credential notice");
+            return;
+        }
+    };
+    if let Err(e) = crate::workers::credential::deliver(&notice, hive).await {
+        // Warn rather than retry: the controller republishes, and a hive that
+        // spun here would hold the queue task off its other two subjects.
+        tracing::warn!(
+            agent = %notice.agent, account = %notice.account, error = ?e,
+            "swarm events: credential delivery failed"
+        );
+        return;
+    }
+    tracing::info!(
+        agent = %notice.agent, account = %notice.account,
+        "swarm events: credential delivered"
+    );
+}
+
 async fn handle_deploy_request(
     coord: &std::sync::Arc<crate::coordinator::Coordinator>,
     payload: &[u8],