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/tools/hivectl.md

@@ -74,12 +74,13 @@ hivectl matrix invite @mara:server --room '#hive-chat:server'  # ...or to a spec
 - `create-user`: for agents, persists the `access_token` to
   `<state>/matrix-token`. Skips registration when the file already
   exists — delete it first to force re-registration.
-- `sync-admin`: ensures the appservice's sender account (`@hive:<server_name>`) exists
+- `sync-admin`: ensures this hive's appservice sender account
+  (`@hive-<hive>:<server_name>`, one per hive) exists
   (the account `hive-c0re` provisions rooms with). Token persisted to the
   access token path. Safe to run again — idempotent.
 - `promote-user`: promotes an already-registered user to homeserver
   admin by an `!admin` command in `#admins`. ⚠️ Needs an admin **sender**,
-  which `@hive:` isn't — promotion is a swarm-level operation, rehomed to
+  which `@hive-<hive>:` isn't — promotion is a swarm-level operation, rehomed to
   the swarm tier rather than granted here, so it has no admin sender to
   call it with from the hive.
 - `reset-password`: asks the admin room to set a new random