matrix, docs: describe promotion/reset as rehomed, not as a pending fix

Both spots hedged the swarm-level framing with a temporal qualifier
("until then", "today") that read as future work awaiting a fix, on
top of the framing itself. Drops the qualifiers; the operations are
swarm-level and rehomed there now, not pending anything from the hive.

docs/integrations/matrix.md

@@ -170,16 +170,17 @@ being the rooms' own creator at power level 100 — there is no homeserver
 admin in any of it, and no Synapse admin API to reach for either, since
 tuwunel has none.
 
-Two operations do need an admin **sender**, and neither works today:
-`hivectl matrix promote-user` and `hivectl matrix reset-password`. Both
-are `!admin …` messages into `#admins:<server_name>`, and tuwunel only
-treats a message as a command when its sender is already an admin. They
-are swarm-level operations and are being rehomed as such; until then
-they fail with the admin room's refusal rather than being served by an
-over-privileged credential that every other call site would also carry.
-The one hive-side path that depends on them is the automatic password
-recovery for an agent whose stored password is gone — the ordinary
-appservice re-login above is unaffected.
+Two operations need an admin **sender**: `hivectl matrix promote-user`
+and `hivectl matrix reset-password`. Both are `!admin …` messages into
+`#admins:<server_name>`, and tuwunel only treats a message as a command
+when its sender is already an admin. They're swarm-level operations,
+rehomed to the swarm tier rather than granted here; from the hive,
+`@hive:` has no admin sender to make that call with, so both get the
+admin room's refusal rather than an over-privileged credential that
+every other call site would also carry. The one hive-side path that
+depends on them is the automatic password recovery for an agent whose
+stored password is gone — the ordinary appservice re-login above is
+unaffected.
 
 <details><summary>Upgrading a hive that used the registration token</summary>
 

docs/tools/hivectl.md

@@ -79,12 +79,13 @@ hivectl matrix invite @mara:server --room '#hive-chat:server'  # ...or to a spec
   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 — this operation is being rehomed at swarm level
-  and doesn't work from the hive today.
+  which `@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
-  password and prints it to stdout. ⚠️ Needs an admin **sender** too, so
-  it doesn't work from the hive today either. Useful if an agent or human lost
-  credentials.
+  password and prints it to stdout. ⚠️ Same admin-**sender** requirement,
+  and the same swarm-level rehoming, so it's unavailable from the hive
+  too. Useful if an agent or human lost credentials.
 - `invite`: invites a matrix user (full `@user:server` or a bare
   localpart, qualified with the homeserver's `server_name`) to the hive
   Space by default, or to a `--room` id / `#alias`. Uses the sender

hive-c0re/src/matrix.rs

@@ -1145,8 +1145,10 @@ pub async fn promote_user_to_admin(
 /// on the next provisioning sweep.
 ///
 /// ⚠️ Same admin-**sender** requirement as [`promote_user_to_admin`], and
-/// the same consequence: `@hive:` is an ordinary account, so this fails
-/// from the hive until the operation is rehomed at swarm level.
+/// the same consequence: `@hive:` is an ordinary account with no admin
+/// sender, and reset, like promotion, is a swarm-level operation rehomed
+/// to the swarm tier rather than granted here — so it has no working
+/// sender from the hive either.
 ///
 /// Returns the new password for use in subsequent `login_user` calls.
 pub async fn reset_user_password(