fix(matrix): order hive-matrix container start after the gateway (resolver)

Per operator review on the PR: when the network module is on, the
matrix container's resolver is the dnsmasq in the gateway container, so
order the matrix container start after the gateway container. This is
robustness for tuwunel's lazy federation lookups, not a boot
requirement — the boot fix is the resolv.conf nameserver line (the
failure was a parse error on an empty resolv.conf, not connectivity).
Soft 'after' (not 'requires') keeps lifecycles decoupled; network.enable
asserts gateway.enable so the gateway container unit always exists.

nix/modules/hive-matrix.nix

@@ -6,6 +6,7 @@
 }:
 let
   cfg = config.services.hyperhive.matrix;
+  networkCfg = config.services.hyperhive.network;
   hyperhiveDomain = config.services.hyperhive.domain;
   effectiveServerName = if cfg.serverName != null then cfg.serverName else hyperhiveDomain;
 
@@ -337,6 +338,29 @@ in
         { ... }:
         {
           system.stateVersion = "26.05";
+
+          # tuwunel hard-fails to boot if `/etc/resolv.conf` has no
+          # `nameserver` line (`Failed to configure DNS resolver ... no
+          # nameservers found in config` → exit 1). This declarative
+          # nixos-container generates its own resolv.conf via resolvconf
+          # and — unlike agent containers, whose resolv.conf is written by
+          # hive-c0re's lifecycle — it has no nameserver source, so it
+          # comes up empty (just `options edns0`). When the hive network
+          # module is on, point it at the dnsmasq resolver the module runs
+          # at `bridgeIp`; this container always shares the host netns
+          # (`privateNetwork = false`), so it reaches `bridgeIp` whether or
+          # not `isolateContainers` is set. With the network module off,
+          # inherit the host's resolv.conf (which carries the host
+          # resolver). See `docs/network.md`.
+          networking = lib.mkMerge [
+            (lib.mkIf networkCfg.enable {
+              nameservers = [ networkCfg.bridgeIp ];
+            })
+            (lib.mkIf (!networkCfg.enable) {
+              useHostResolvConf = true;
+            })
+          ];
+
           services.matrix-tuwunel = {
             enable = true;
             package = cfg.package;
@@ -379,5 +403,22 @@ in
         cfg.httpPort
       ];
     };
+
+    # When the hive network module is on, the matrix container's resolver
+    # is the dnsmasq that runs in the gateway container (bound at
+    # `bridgeIp`). Order the matrix container start after the gateway
+    # container so the resolver is up before tuwunel's first federation
+    # lookups. tuwunel boots fine without this — it configures the resolver
+    # from `/etc/resolv.conf` at startup and only queries on-demand (the
+    # boot failure this module fixes was an *empty* resolv.conf, a parse
+    # error, not a connectivity one) — so this is robustness, not a boot
+    # requirement. Soft `after` ordering (not `requires`) keeps the matrix
+    # container's lifecycle decoupled from the gateway's. `network.enable`
+    # asserts `gateway.enable`, so the gateway container unit always exists
+    # here. (Declarative `containers.<n>` → `nixos-container@<n>.service`,
+    # per the hive-ci precedent.)
+    systemd.services."nixos-container@hive-matrix".after = lib.mkIf networkCfg.enable [
+      "nixos-container@hive-gateway.service"
+    ];
   };
 }