docs(network): fix stale forge/matrix zone claim in resolver behaviour

Verified against nix/host-modules/hive-gateway/dnsmasq.nix + gateway.localNames
contributors (hive-forge, hive-matrix, swarm-authelia): forge and the matrix
gateway vhost are swarm-domain names (forge.<swarm-domain>, chat.<swarm-domain>),
not sub-domains of the hive's own domain as the doc previously claimed.

docs/network.md

@@ -112,14 +112,19 @@ schemes pick their own.
 
 ## Resolver behaviour
 
-dnsmasq is **authoritative** for the hive's own zones — answers
-`<hive-domain>`, `forge.<hive-domain>`, `matrix.<hive-domain>` and —
-on the host running it — the swarm's `auth.<swarm-domain>`
-queries with the bridge IP (where nginx is reachable). Everything
-else is forwarded to the host's own resolvers: dnsmasq runs on the host
-and reads the host's `/etc/resolv.conf` directly. Containers don't need
-to know the upstream — they query the bridge IP and dnsmasq does the
-right thing per-name.
+dnsmasq is **authoritative** for the hive's own zone (`<hive-domain>`)
+plus whatever swarm-service names this host contributes via
+`gateway.localNames` — `forge.<swarm-domain>` and `chat.<swarm-domain>`
+(matrix) when this host runs those services, and `auth.<swarm-domain>`
+when it runs authelia — answering each with the bridge IP (where nginx
+is reachable). Note forge and matrix are swarm-domain names, not
+sub-domains of `<hive-domain>`: a swarm runs one forge and one
+homeserver, so their names belong to the swarm rather than to whichever
+hive happens to host them. Everything else is forwarded to the host's
+own resolvers: dnsmasq runs on the host and reads the host's
+`/etc/resolv.conf` directly. Containers don't need to know the
+upstream — they query the bridge IP and dnsmasq does the right thing
+per-name.
 
 There is deliberately no fallback `server=`: dnsmasq queries all known
 upstreams in parallel, so a hardcoded public resolver would take a share