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/snapshot-store.md

@@ -10,9 +10,9 @@ assumptions:
 - **It's not the swarm controller**, and doesn't depend on one. It's
   a NixOS host role: a btrfs subvolume tree, a socket-activated
   receiver, and the `wg-hive` interface the swarm module already brings
-  up. That's why it can be deployed before any controller exists.
+  up. That's why you can deploy it before any controller exists.
 - **It's not a backup product.** It happens to hold the data a backup
-  would hold, and it should be operated accordingly (see
+  would hold, and you should operate it accordingly (see
   [Operating it](#operating-it)) --- but nothing in it does scheduling,
   verification, or restore orchestration.
 
@@ -37,14 +37,14 @@ The store host is a swarm member like any other: it gets an entry in
 `services.hyperhive.swarm.hives`, the same directory every host holds. See
 [swarm/](../swarm/README.md) for the mesh itself.
 
-Note that the mesh is gated on `deploy.wireguard.enable`, **not** on
+Note that `deploy.wireguard.enable` gates the mesh, **not**
 `c0re.enable` --- a store host runs no hive and would otherwise get no
 `wg-hive` interface at all.
 
 ## Pointing a hive at it
 
-The block above configures the host that _receives_. Every hive that
-_pushes_ separately needs to be told where the store is:
+The block above configures the host that _receives_. You must tell every
+hive that _pushes_ separately where the store is:
 
 ```nix
 services.hyperhive.swarm.snapshotStore = {
@@ -84,9 +84,9 @@ deliberate rather than an omission.
 WireGuard's cryptokey routing already binds a peer's source address to
 its public key: the swarm module configures each peer with
 `allowedIPs = [ peer.wireguardAddress ]`, so a packet arriving from
-that address provably came from the holder of that private key. A
-packet that reaches the receiver has therefore already been
-authenticated by the kernel.
+that address provably came from the holder of that private key. So by
+the time a packet reaches the receiver, the kernel has already
+authenticated it.
 
 Layering TLS client certs on top would authenticate _the same fact_ a
 second time, and add a credential with an expiry --- a migration that
@@ -95,7 +95,7 @@ you need to move an agent.
 
 ## One subvolume per agent, not per hive
 
-The destination is keyed by **agent**.
+The receiver keys the destination by **agent**.
 
 This isn't cosmetic. After a migration, an agent's next incremental
 send arrives from a _different_ hive than the previous one. Keying by
@@ -130,7 +130,7 @@ state.
 
 Binding isn't sufficient on its own. NixOS's firewall is default-deny
 and filters in netfilter, _before_ a packet reaches a bound socket, so
-the port is opened explicitly --- and scoped to the mesh interface:
+the module explicitly opens the port --- scoped to the mesh interface:
 
 ```nix
 networking.firewall.interfaces.wg-hive.allowedTCPPorts = [ cfg.port ];
@@ -159,8 +159,8 @@ The boundary is the machine. The intended deployments are:
   host.
 
 The second is worth keeping deliberately, and not only for
-convenience: it means the confined path is exercised by every local
-deployment. The usual failure mode for an isolated variant is that
+convenience: it means every local deployment exercises the confined
+path. The usual failure mode for an isolated variant is that
 nobody runs it day to day, so it rots and is discovered broken in
 production.
 
@@ -186,7 +186,7 @@ The snapshot covers an agent's **state subvolume**, which is the parent
 of `state/`, `claude/` and `harness/` (see
 [`docs/agent-lifecycle/persistence.md`'s btrfs subvolume
 section](../agent-lifecycle/persistence.md#btrfs-subvolumes-for-varlibhyperhiveagentsname)
-for how and when that subvolume is created). Consequences:
+for how and when hive-c0re creates that subvolume). Consequences:
 
 - The Claude session (`claude/`) travels, so a restored agent keeps its
   live `--continue` session rather than needing to log in again.