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

@@ -403,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"
+    ];
   };
 }