docs(matrix): fix the bug-as-behaviour and must wording mara flagged

matrix.md no longer documents the .well-known/discovery domain
mismatch as a fact to work around (that's #4878's fix to make);
same fix applied to gateway.md's Discovery flow section, which
stated the identical bug and told the operator how to route
around it.

The serverName-pinning note no longer says the module requires
pinning it (nothing enforces that) — it states the consequence of
not pinning it instead.

Refs #3902

docs/integrations/matrix.md

@@ -40,10 +40,7 @@ Two distinct hostnames:
   *irrevocably* in every `@user:<server_name>` and `!room:<server_name>`
   identifier minted on this homeserver. You can't change it later
   without abandoning every account and chat history. Defaults to the
-  bare `services.hyperhive.swarm.domain`. The gateway serves the
-  `.well-known/matrix/{client,server}` discovery routes on the matrix
-  host's **hive** domain, not the swarm domain
-  ([Discovery flow](../networking/gateway.md#discovery-flow-matrix)).
+  bare `services.hyperhive.swarm.domain`.
 - **`gatewayHost`** — the API listener hostname, where the gateway's
   matrix vhost proxies `/_matrix/*` to tuwunel. Defaults to
   `chat.<services.hyperhive.swarm.domain>`. Set to `null` to skip the
@@ -65,9 +62,8 @@ longer answers.
 <details><summary>Pinning <code>serverName</code> on a homeserver with existing ids</summary>
 
 `serverName` defaults to the bare `services.hyperhive.swarm.domain`. A
-homeserver must set `serverName` to the value that minted its existing
-ids — see above for why a different value strands existing users and
-rooms:
+homeserver that changes `serverName` after minting ids strands its
+existing users and rooms — keep the value it minted them under:
 
 ```nix
 services.hyperhive.swarm.matrix = {