matrix: one sender account and one sender token per hive

A swarm runs one homeserver and every hive on it logged in as the same
`@hive:` localpart, holding the same access token out of one swarm-wide
store path. That is one matrix identity for N hives: the homeserver
cannot attribute an action to the hive that took it, and revoking one
hive's standing revokes every hive's.

Three changes, and the third is the one that makes the other two real:

- **The localpart carries the hive's name** (`hive-<hive>`), derived in
  one place, `swarm_secret_client::matrix::hive_localpart`.
  `hive-matrix.nix` renders the same string as the appservice
  registration's `sender_localpart`, so the shared account stops being
  created rather than merely stops being used.
- **The store path is templated by hive**, not a constant. The
  "a swarm runs one homeserver, so this is a constant rather than a
  parameter" rationale went with it; it stopped holding the moment two
  hives shared the homeserver it describes.
- **The path moved out from under the grant every hive has.** It sat at
  `swarm/services/matrix/sender-token`, inside the
  `secret/data/swarm/services/*` read stanza `policy::render` gives every
  hive. It now sits under that hive's own stanza,
  `secret/data/swarm/hives/<hive>/*`, which interpolates the reader's
  name — so a hive reads its own token and is refused another's. The
  policy renderer itself is unchanged: narrowing the `services/*` grant
  would break the OIDC-secret read it exists for, and moving the
  credential is what this needed instead. A policy test walks the
  rendered stanzas and asserts none of hive alpha's covers hive beta's
  sender token, so a later stanza that widened it fails here.

`swarm-matrix-ctl` takes a new required `MATRIX_MINT_HIVE` and writes
that hive's path; its store grant in `swarm-bao.nix` follows, scoped to
one hive's leaf via the new `deploy.bao.matrixCtlHiveName` (defaulting to
this host's `hiveName`) rather than a `hives/*` wildcard, which would
hand the matrix container every hive's token back.

Migration: no outage at deploy. `ensure_hive_user` short-circuits on the
local token file, so a hive keeps running on what it has; with no such
file it reads the new per-hive path, finds nothing, and falls through to
the existing register-or-appservice-login ladder against its own
localpart — which needs only the per-hive `as_token` on local disk. The
old shared object is read by nothing afterwards. Rooms do not follow the
identity, and that is the one operator step; both ways out are written
into `docs/integrations/matrix.md`.

No admin standing is granted to the per-hive accounts: `admin_execute`
stays empty and the assertion pinning it is untouched.

docs/trust-boundary/security.md

@@ -94,6 +94,20 @@ it.
 the grant per hive (and pay for the re-emission), or give each agent container
 its own store identity so credentials never pass through a hive at all.
 
+### Per-hive credentials live under the hive kind, not beside a service
+
+`swarm_secret_client::policy` scopes the **hive** stanza narrowly (unlike the
+agent and service stanzas above) because a hive's own path names it, so
+scoping to the reader's own name costs nothing and drifts nowhere. That only
+holds if a credential that must be one-per-hive is actually stored under the
+hive kind — the matrix sender token was originally published to
+`swarm/services/matrix/sender-token`, under the **service** kind, and so was
+readable by every hive though it belonged to only one. Making it per-hive meant
+moving its path under the hive kind, not narrowing the service stanza's grant.
+**A credential that must be one-per-hive goes under `Kind::Hive`**; putting it
+under `Kind::Service` and expecting the grant to scope it — that's the mistake
+this note exists to stop.
+
 ### Threat model: prompt injection → confused deputy
 
 The realistic adversary **never needs to breach the container**. They supply