fix(#3297): reject a publish template that names no hive

`--hive-publish-subject` exists to put a second stream inside one hive's
namespace. A template with no `{hive}` in it expands to the same subject
for every hive, so the option whose only purpose is scoping becomes the
way to remove it — silently, and only in the deployment that set it.

`Policy::new` returns a `Result` rather than checking at the call site:
that makes an unscoped policy unconstructible instead of merely
unlikely, the same reason `grant` takes its permissions by value. The
error names the offending template and says what goes wrong with it,
because an operator meets it at boot with no other context.

Also documents what the prefix match does not do. A client id is a hive
here because it starts with the configured prefix, not because it
appears in the roster — the responder runs in a container and cannot see
`swarm.hives`. Passing the roster in would close that and would also be
a second place deciding who may connect as what, which `introspect`'s
docs argue against for the same reason admission lives in one place.

The two intra-doc links to `open_or_create` become plain backticks.
Un-gating the `status` module means its module doc now renders in builds
without the `kv` feature, where the item it linked does not exist.

swarm-queue-client/src/status.rs

@@ -7,7 +7,7 @@
 //! repeated across crates is an agreement nothing checks.**
 //!
 //! The name is the obvious half. The sharper half is the *config*: both
-//! ends open the bucket with [`crate::status::open_or_create`], because either may
+//! ends open the bucket with `open_or_create`, because either may
 //! arrive first on a fresh swarm and neither can assume the other has
 //! run. If the two ends passed different `Config`s, whichever created it
 //! would win and the other's `get_key_value` would succeed against a
@@ -15,8 +15,10 @@
 //! nobody chose. Sharing the constructor makes the race have one outcome
 //! instead of two.
 //!
-//! The bucket *name* is unconditional; only [`open_or_create`] is behind the
-//! `kv` feature. A third end names the bucket without ever opening it — the
+//! The bucket *name* is unconditional; only `open_or_create` is behind the
+//! `kv` feature. (Named in backticks rather than linked: with `kv` off the item
+//! does not exist, and an intra-doc link to it fails the rustdoc gate in
+//! exactly the configuration this split exists to support.) A third end names the bucket without ever opening it — the
 //! auth-callout responder, which derives the subjects a hive may publish to
 //! from it — and it speaks neither `jetstream` nor `kv`. Gating the name too
 //! would have made that consumer choose between a JetStream stack it does not