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-controller/Cargo.toml

@@ -24,7 +24,11 @@ serde_json.workspace = true
 # every other participant - a hive publishing its own status runs the same
 # code with a different client id. Two copies of credential handling is one
 # token-refresh fix that has to be found twice.
-swarm-queue-client.workspace = true
+#
+# `kv` for the same reason one level in: the status bucket's name and
+# creation config are shared with the hive that writes it, so this end does
+# not get to declare them privately.
+swarm-queue-client = { workspace = true, features = ["kv"] }
 tokio.workspace = true
 tracing.workspace = true
 tracing-subscriber.workspace = true