docs: fix genuine passive-voice hits in docs/networking

Eighth batch of the ongoing write-good.Passive pass (hyperhive#4042):
read all 69 hits across network.md/snapshot-store.md/gateway.md in
context and rewrote 34 with a clearly nameable actor -- mostly
hive-c0re, dnsmasq, nginx, or a specific systemd unit/fn named right
there or a sentence or two earlier. snapshot-store.md's operator-facing
prose ("you can deploy it", "you must tell every hive") reuses this
doc's own established "you" address (already present two sentences
away in one case) rather than inventing a new register.

Left 35 alone -- the largest leave-alone count yet, dominated by two
shapes gateway.md is dense with: negative-capability/requirement
idioms ("no X is required/needed/exposed", "can't be added/wired",
"must not be exposed") and predicate-adjective state descriptions
("is misconfigured"/"is broken" in negative-contrast "not that X"
framing, "is privileged" matching the established "is trusted" bucket,
"is closed/internal" deployment-posture, "is encrypted and
unauthenticated" connection-state pair). Also: two "X was removed"
changelog-style facts with no actor clause (same family left alone in
the scheduler batch), a gerund nix-conditional pair ("X being enabled
and Y being set are assertions, not documentation"), and a passive
embedded inside an already-active sentence ("X controls whether Y is
opened" -- the real verb is already active).

One caught-and-reverted mid-edit mistake: an early attempt at the
"nginx is handed the leaf" fix landed on the wrong paragraph (an
unrelated CA-generation sentence two paragraphs up) and left a
nonsensical forward-reference behind. Caught by re-reading the diff
before running vale, not by the count -- same discipline as the
docs/process batch's original catch. Reverted cleanly and reapplied at
the actual target sentence.

One small sibling-consistency fix beyond pure voice-flipping: "The
gateway emits the following headers..." (rewritten) sat two paragraphs
above "a header is added alongside the other security headers" (still
passive) describing the same mechanism -- rewrote the second to match
("the gateway adds a header...") rather than leave one active and one
passive version of the identical fact sitting near each other.

Verified via vale before/after: 69 -> 35 write-good.Passive hits,
exactly the 35 left alone above; error count and other warning
categories unchanged. Re-read every changed line in full surrounding
context after editing before running the final vale check.

docs/networking/network.md

@@ -55,8 +55,8 @@ 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 and the service containers query `bridgeIp:53`; hive
-  zones are answered authoritatively with the bridge IP, everything else
+- **DNS** — agents and the service containers query `bridgeIp:53`; dnsmasq
+  answers hive zones 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
@@ -99,7 +99,7 @@ listener on `bridgeIp` is on the host's bridge interface.
 }
 ```
 
-Requires `services.hyperhive.domain` to be set — the dnsmasq resolver
+You must set `services.hyperhive.domain` — the dnsmasq resolver
 is authoritative for `<hive-domain>` and its sub-domains. You don't
 write it: it's read from this hive's entry in the swarm directory
 (`docs/swarm/README.md` § Hive identity config).
@@ -123,8 +123,8 @@ 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
+hive happens to host them. dnsmasq forwards everything else to the host's
+own resolvers: it 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.
@@ -224,11 +224,11 @@ address arithmetic.
 `hive-c0re` reads `HIVE_NETWORK_BRIDGE` + `HIVE_NETWORK_SUBNET` and passes
 `PRIVATE_NETWORK=1`, `LOCAL_ADDRESS=` (empty), `HOST_ADDRESS=<bridge-ip>`,
 and `HOST_BRIDGE=<bridgeName>` via `lifecycle::set_nspawn_flags` when
-creating or updating containers. Both variables are validated **once at
+creating or updating containers. hive-c0re validates both variables **once at
 daemon startup**, not per container: they're process-global, so a
 missing or malformed value is a misconfigured daemon rather than one bad
 container, and failing at boot gives a single diagnostic instead of one
-per agent. No non-isolated mode exists to fall back to. `LOCAL_ADDRESS` is left empty so the
+per agent. No non-isolated mode exists to fall back to. hive-c0re leaves `LOCAL_ADDRESS` empty so the
 container's dhcpcd acquires an address from the bridge dnsmasq pool
 (`networking.useDHCP = true` in `nix/agent-modules/network.nix`). This applies uniformly
 to all containers — agents and service containers alike.
@@ -238,8 +238,8 @@ to all containers — agents and service containers alike.
 so a non-`.1` operator override still resolves to wherever the bridge
 actually lives). It's **load-bearing**: nixos-container's container-side
 network setup only installs a default route (`ip route add default via
-$HOST_ADDRESS`) when `HOST_ADDRESS` is non-empty. In bridge mode the
-host-side address/route setup is skipped, so writing it only affects the
+$HOST_ADDRESS`) when `HOST_ADDRESS` is non-empty. In bridge mode
+nixos-container skips the host-side address/route setup, so writing it only affects the
 container's default route — without it the container comes up with an IP
 but no path off the bridge subnet (no internet, no `api.anthropic.com`).
 
@@ -249,8 +249,8 @@ nixos-container copies the **host's** `/etc/resolv.conf` into the container
 at every start. The host resolver (for example `127.0.0.53` from systemd-resolved,
 or a LAN router) is unreachable from a private netns and isn't
 authoritative for the hive's own zones, so it's replaced with the
-bridge dnsmasq at boot. Because the copy happens on every start, a
-declarative `environment.etc."resolv.conf"` would be clobbered — so the
+bridge dnsmasq at boot. Because the copy happens on every start, it
+would clobber a declarative `environment.etc."resolv.conf"` — so the
 wiring is runtime:
 
 - `hive-priv` drops a marker file (`/etc/hyperhive-bridge-dns`, carrying the