docs(nh3-dev): Hermes bearer rotation hold released

svos-dev split their Bifrost wall's HS256 signing key off the Hermes Bearer
(svos main 7165272), so nh3-dev/hermes/api-server-key is free to rotate again.
The previous note said do-not-rotate and would have made a future session
refuse a legitimate rotation on stale grounds.

Not rotating now: the key was minted today, is vaulted, and has never been
exposed — rotation is a hygiene action with a trigger, and none applies. What
changed is the capability, which is what the record needs to reflect.

Also records two things for when the svos_miranda plugin arrives: it will
reference the dispatch key rather than the Bearer (expected, not a defect), and
its tools array is legitimately seven or eight entries because repo_read is
conditional on a config block SVOS owns. A third number is a real fault.

servers/nh3-dev/README.md

@@ -105,11 +105,22 @@ local Bash already executes here — no SSH-to-self needed for non-privileged wo
   present and unused; `provider: custom` is explicit so it is not a candidate,
   and `hermes fallback list` is empty, so there is no degraded-mode route that
   quietly re-bills z.ai. Miranda fails rather than fails over if LiteLLM is down.
-- ⚠ **Do not rotate `nh3-dev/hermes/api-server-key` yet.** SVOS currently reuses
-  that value as the HS256 signing key on its Bifrost wall, so a rotation would
-  401 every Miranda tool call. svos-dev is splitting theirs off (operator-
-  approved 2026-09-14) and will confirm when it lands; rotation is safe after
-  that, not before.
+- **`nh3-dev/hermes/api-server-key` is free to rotate** (hold released
+  2026-09-14, svos main `7165272`). It had been locked: SVOS signed its own
+  Bifrost wall's HS256 dispatch tokens with the same value, so a routine
+  rotation would have 401'd every Miranda tool call — silently, since losing
+  signature validity does not raise. SVOS now verifies against its own secret
+  (`SVOS_BIFROST_DISPATCH_KEY`, vaulted at `nh3-dev/svos/bifrost-dispatch-key`,
+  theirs — nothing here reads it), and the Bearer has exactly one job again.
+  Rotating it now only means svos-dev repoints `SVOS_HERMES_API_KEY`.
+  ⚠ The invariant did not rot, its *precondition* did: "one shared secret" was
+  sound while SVOS owned both ends of the key and stopped being sound the moment
+  the runtime became externally managed. Worth remembering when any other peer
+  reuses a credential across a boundary we control.
+  ⚠ When the `svos_miranda` plugin arrives for `hermes plugins validate`, it
+  will reference the **dispatch key, not the Bearer** — expected, not a defect.
+  Assert its per-row `tools` array has **seven or eight** entries (`repo_read` is
+  config-conditional on SVOS's side); any other number is a real fault.
 - **bloom_music dev** — `~/development/bloom_music`; its `web/` test harness uses
   Playwright headless Chromium for OSMD browser-geometry assertions.
 - **The Booth** — ephemeral media drop board (`:8090`, `booth.service`), from