swarm: split the deploy subject per hive

Per mara on the PR: *"split by hive. its not a security thing, just so
hives dont get messages they dont care about."*

She agreed with the finding and still wanted the split, which is the
part worth recording. I measured that a per-hive subject gives no
confidentiality — `sub` is unrestricted, so a hive that wanted another's
messages could subscribe to them — and concluded it bought nothing.
"Nothing" is a claim over every axis and I had checked one. The axis I
never priced: every hive in the swarm being woken by every other hive's
deploys.

So `deploy_subject(hive)` replaces the single literal, and the payload
drops `hive` to carry only the agent — the subject names the hive, and
two places stating one fact are free to disagree. The hive subscribes to
its own subject and no longer filters.

The grant is a wildcard rather than a subject per hive because the
responder has no roster: it cannot enumerate hives, and a grant that had
to track one would be a second place to get the list wrong — the same
argument `hive_name`'s doc makes about admission.

The negative test gets stronger rather than merely adapted. Splitting
the family makes "another hive's subject" and "its own" separate strings
for the first time, so it now asserts a hive reaches neither, nor the
wildcard.

swarm-queue-client/src/lib.rs

@@ -173,26 +173,35 @@ pub mod status;
 /// permitted at all — speaks neither `jetstream` nor `kv`.
 pub const KNOWLEDGE_SUBJECT: &str = "$SWARM.knowledge";
 
-/// The subject the swarm controller publishes on to ask a hive to rebuild one
-/// of its agents. Same shape as [`KNOWLEDGE_SUBJECT`]: one writer, every hive
-/// subscribes, and it lives here for the same three-crate reason.
+/// The subject the swarm controller publishes on to ask `hive` to rebuild one
+/// of its agents. Lives here for the same three-crate reason as
+/// [`KNOWLEDGE_SUBJECT`], but unlike it this is a **family, one subject per
+/// hive** — a hive subscribes to its own and is never woken by a deploy meant
+/// for someone else.
 ///
-/// # Swarm-wide, not per-hive, and that is deliberate
-///
-/// A `$SWARM.deploy.<hive>` family would *look* like isolation and provide
-/// none: the auth-callout responder scopes **publish** only, leaving `sub`
-/// unrestricted, so any hive could subscribe to another's subject just as
-/// easily as to its own. Until `sub` is scoped, the per-hive split costs a
-/// wider grant and buys nothing — so the addressing lives in the payload and
-/// each hive filters on its own name, exactly as the knowledge event fans out.
-pub const DEPLOY_SUBJECT: &str = "$SWARM.deploy";
+/// ⚠️ **That split is about noise, not confidentiality.** The auth-callout
+/// responder scopes *publish* only and leaves `sub` unrestricted, so a hive
+/// that wanted another's messages could still subscribe to them. What the
+/// family buys is that it does not receive them by default.
+#[must_use]
+pub fn deploy_subject(hive: &str) -> String {
+    format!("{DEPLOY_SUBJECT_PREFIX}.{hive}")
+}
 
-/// What a [`DEPLOY_SUBJECT`] message carries.
+/// The publish grant covering every [`deploy_subject`], for the one client
+/// that may send them. A wildcard rather than a subject per hive because the
+/// responder has no roster — it cannot enumerate hives, and a grant it had to
+/// keep in step with one would be a second place to get the list wrong.
+pub const DEPLOY_SUBJECT_WILDCARD: &str = "$SWARM.deploy.*";
+
+/// Shared by [`deploy_subject`] and [`DEPLOY_SUBJECT_WILDCARD`] so the two
+/// cannot drift into naming different families.
+const DEPLOY_SUBJECT_PREFIX: &str = "$SWARM.deploy";
+
+/// What a [`deploy_subject`] message carries.
 ///
-/// The knowledge event has no payload — every hive does the same thing on
-/// receipt. This one is addressed, so both ends have to agree on the fields,
-/// which is why the type lives beside the subject rather than in whichever
-/// crate happened to need it first.
+/// Only the agent: the subject already names the hive, and repeating it here
+/// would be two places stating one fact, free to disagree.
 ///
 /// ⚠️ **A trigger, not the config.** The hive already tracks the agent's
 /// config repo; putting desired state on the wire would make this message a
@@ -200,9 +209,6 @@ pub const DEPLOY_SUBJECT: &str = "$SWARM.deploy";
 /// missed a message would then be wrong rather than merely late.
 #[derive(Debug, Clone, PartialEq, Eq, serde::Serialize, serde::Deserialize)]
 pub struct DeployRequest {
-    /// Which hive should act. Every hive receives the message; the one whose
-    /// own name this matches is the one that rebuilds.
-    pub hive: String,
     /// The agent to rebuild, as the swarm knows it.
     pub agent: String,
 }