refactor(swarm-queue-client): share the hive-status bucket's name and shape

The bucket has two ends in two crates: a hive writes its own key, the
controller reads every key. `swarm-controller` declared the name as a
private const with a doc comment arguing that "reader and writer must
name the same bucket" — an argument the writer, in another crate, could
not obey.

The name is the mild half. Both ends do get-or-create, because either may
come up first on a fresh swarm and neither can assume the other has run.
Two `Config`s that drift means whichever end created the bucket wins and
the other's `get_key_value` succeeds against a bucket it did not ask for:
no error, no log, just a retention policy nobody chose. Sharing the
constructor gives that race one outcome.

Behind a default-off `kv` feature, so the crate's other consumer — the
auth-callout responder, which speaks the connect and nothing else — still
pulls neither `jetstream` nor `kv`. That was the actual reason the
feature was excluded when this crate was extracted; the flag preserves
it. The surface is deliberately narrow: one bucket's name and creation
config, not a general KV facade.

swarm-queue-client/Cargo.toml

@@ -4,11 +4,23 @@ version.workspace = true
 readme = "README.md"
 edition.workspace = true
 
+[features]
+# OFF by default, and that default is the point: the auth-callout responder
+# consumes this crate for the connect alone and speaks neither `jetstream`
+# nor `kv`. A consumer that needs the status bucket says so in its own
+# Cargo.toml, so the requirement stays visible where it is incurred.
+#
+# What is behind the flag is deliberately narrow - the *name and shape* of
+# one bucket two crates open from opposite ends (`src/status.rs`), not a
+# general "KV support" surface. The crate's job still ends at a connected
+# client; the exception exists because an agreement between two crates has
+# to live in one of them, and neither end of that bucket is senior to the
+# other.
+kv = ["async-nats/kv"]
+
 [dependencies]
-# No `kv`/`jetstream` feature here on purpose: this crate's job ends at a
-# connected client. What a consumer does with it - KV for the controller and
-# the hive, plain messaging for anything later - is the consumer's business,
-# and its Cargo.toml is where that requirement should be visible.
+# Bare (no `kv`/`jetstream`) unless a consumer opts into the `kv` feature
+# above - the connect itself needs none of them.
 async-nats.workspace = true
 reqwest.workspace = true
 serde.workspace = true