hive-forge: resolve through the hive's dnsmasq

The forge container used the host's resolvers, where the swarm domain has
no records — so every outbound call to a swarm name failed with "no such
host". Forgejo's webhook deliveries died there: knowledge, config-pr and
vcs-activity alike, which is why the swarm-controller's receiver has never
logged a verified delivery and knowledge propagation has been running on
its hourly fallback.

An earlier fix taught the container authelia's name with a `networking.hosts`
entry. That covered one name and left the rest, so use the resolver every
other service container already uses and drop the override — hive-matrix
records why a second answer that can disagree with the first is worse than
none.

Closes #3824

docs/network.md

@@ -55,9 +55,12 @@ The flows, end to end:
 
 - **DHCP** — agent `dhcpcd` broadcasts on `eth0` → veth → bridge →
   host firewall (udp 67 hole) → dnsmasq pool → lease + router option.
-- **DNS** — agents query `bridgeIp:53`; hive zones are answered
-  authoritatively with the bridge IP, everything else forwards to the
-  host's resolvers (see *Resolver behaviour* below).
+- **DNS** — agents and the service containers query `bridgeIp:53`; hive
+  zones are answered authoritatively with the bridge IP, everything else
+  forwards to the host's resolvers (see *Resolver behaviour* below). Each
+  container points its own `resolv.conf` there, and one that instead
+  inherits the host's resolves no swarm name at all — those records exist
+  only on the bridge.
 - **HTTP** — `forge.` and `chat.` (under `swarm.domain`) plus the hive's
   own dashboard name resolve to the bridge IP, land on nginx
   `:80`/`:443`, and proxy to forgejo