keep the matrix appservice registration in bao, with the host file as the last copy

docs/integrations/matrix.md

@@ -129,10 +129,11 @@ creation doesn't depend on registration being open to anyone who learns
 a token.
 
 1. **`swarm-matrix-ctl appservice render`**, inside the `hive-matrix`
-   container and before tuwunel starts, mints the registration's
-   `as_token` and its spec-required `hs_token` when they're missing, and
-   renders the registration to
-   `/var/lib/swarm-matrix-appservice/swarm.yaml` (mode `0600 root:root`).
+   container and before tuwunel starts, renders the registration to
+   `/var/lib/swarm-matrix-appservice/swarm.yaml` (mode `0600 root:root`)
+   from the `as_token` and spec-required `hs_token` beside it. It mints
+   them only on a container that has none, and never reaches the store, so
+   a store outage can't keep the homeserver down.
 2. **systemd `LoadCredential=`** copies the registration into
    `/run/credentials/tuwunel.service/swarm-appservice.yaml`, owned by
    tuwunel's dynamic user with mode `0400`, at service start. The source
@@ -168,13 +169,21 @@ namespace non-exclusive. It's the swarm's identity on the homeserver:
 `swarm-controller` creates every agent's account and every hive's sender
 account with it.
 
-`swarm-matrix-ctl appservice render` mints its tokens inside the
-`hive-matrix` container, before tuwunel starts, and renders the
-registration tuwunel loads as a credential. `appservice publish`
-then writes its `as_token` to
-`swarm/controller/swarm-controller/matrix/appservice-token`. No hive's
-policy reaches that path: only matrix-ctl (which writes it) and
-`swarm-controller` (which reads it) hold a grant to it.
+The swarm secret store holds the registration's tokens, at
+`swarm/controller/swarm-controller/matrix/appservice-registration`.
+`swarm-matrix-ctl appservice render` renders the registration tuwunel
+loads as a credential from the copy of them in the `hive-matrix`
+container, before tuwunel starts and without the store.
+`appservice sync` runs beside tuwunel on a timer. The store's tokens win:
+when they differ from the container's, it writes them there. It
+restarts tuwunel whenever the registration is newer than tuwunel's last
+start, so the next run retries one that failed after writing. A store that holds none takes the container's
+tokens with a create-only write, so a running swarm keeps its value, and
+a container that has none mints a pair. `sync` then writes the `as_token`
+to `swarm/controller/swarm-controller/matrix/appservice-token`. No hive's
+policy reaches either path: only matrix-ctl (which holds `create` and
+`read` on the registration, and writes the token) and `swarm-controller`
+(which reads only the token) hold a grant.
 
 `@swarm` is the **one** account the homeserver promotes to admin at boot
 (`admin_execute`). Only those two principals read its token, which is
@@ -277,9 +286,9 @@ required.
 
 <details><summary>Appservice identity</summary>
 
-`swarm-matrix-ctl appservice render` mints the appservice tokens and
-renders the registration before tuwunel starts, so every boot has both
-halves.
+`swarm-matrix-ctl appservice render` renders the registration from the
+container's copy of the appservice tokens before tuwunel starts, so every
+boot has both halves, with the store up or down.
 
 <!-- vale write-good.Passive = NO -->
 - **Access tokens live on the device that minted them.**
@@ -289,8 +298,8 @@ halves.
   (above); a hive's sender account is never promoted.
 - **The value that matters lives at
   `swarm/controller/swarm-controller/matrix/appservice-token`.**
-  `appservice publish` writes the container's copy there whenever the
-  store's differs, and `swarm-controller` reads it from there.
+  `appservice sync` writes it there whenever the store's differs from the
+  registration's `as_token`, and `swarm-controller` reads it from there.
 <!-- vale write-good.Passive = YES -->
 
 </details>