docs: clear write-good.Passive hits in docs/trust-boundary/boundary.md

6 genuine passive-voice rewrites (actor named — the core daemon,
hyperhive, the adminUsers option; one flipped subject to match the
table it introduces; two converted to active/imperative phrasing);
2 false positives left untouched — the already-established 'is
tracked as [area:ops] issues' pattern, and a design-intent
contrastive idiom ('ownership is declared, not repaired') matching
the unflagged sibling phrase 'a DAG is declared, not described' in
coordinator.md.

docs/trust-boundary/boundary.md

@@ -49,17 +49,17 @@ runs in a private netns behind the hive bridge, and there is no
 shared-netns mode. See `docs/networking/network.md`.
 
 Concretely, the core daemon's dashboard `/api` carries **no
-application-layer authentication** — operator-authority routes are served
-unauthenticated at the HTTP layer. Their protection is entirely (a) the
+application-layer authentication** — the core daemon serves operator-authority
+routes unauthenticated at the HTTP layer. Their protection is entirely (a) the
 gateway, which fronts all operator traffic and is where operator auth lives,
 and (b) network isolation, which keeps agents — and `hive-ci`'s untrusted PR
 builds — off host-loopback so nothing can reach `127.0.0.1:<dashboard_port>`
 directly. This is deliberate given the load-bearing role of network isolation
-above, but it's a standing invariant: the `/api` must never be bound to a
-non-loopback address or exposed outside the gateway, and every new
-operator-authority route inherits that assumption. `hive-ci` is treated like an
-agent for this purpose — it runs untrusted PR code and is netns-isolated for
-the same reason.
+above, but it's a standing invariant: the `/api` must never bind to a
+non-loopback address or get exposed outside the gateway, and every new
+operator-authority route inherits that assumption. hyperhive treats `hive-ci`
+like an agent for this purpose — it runs untrusted PR code and is
+netns-isolated for the same reason.
 
 The boundary rests on three layers:
 
@@ -96,8 +96,8 @@ exact same path, so the group grant always holds.
 
 ### the per-agent socket dir
 
-`/run/hive-agent/<name>/` is shared by **three principals that share no
-group**, which is why its mode is what it's:
+**Three principals that share no group** reach `/run/hive-agent/<name>/`,
+which is why its mode is what it's:
 
 | principal           | reaches                                  | needs        |
 | ------------------- | ---------------------------------------- | ------------ |
@@ -127,8 +127,8 @@ nginx reaches all of `/run/hive-agent` as a plain host path. Dropping
 ⚠️ **The gateway's nginx and dnsmasq are host services, next to
 `hive-c0re`** (see `docs/networking/gateway.md`) — there is no namespace between
 them and the rest of the host. That costs no network isolation: nginx
-binds the host's `:80`/`:443` and reaches `localhost` upstreams, which a
-netns would have to be opened up for anyway.
+binds the host's `:80`/`:443` and reaches `localhost` upstreams, which
+would require opening a netns anyway.
 🔑 It does mean nothing _implicitly_ scopes the privileged reload verb —
 see [`docs/trust-boundary/security.md`](security.md#hive-c0re-privilege-separation) for
 how `PrivRequest::ReloadGatewayNginx`'s containment works.
@@ -148,7 +148,7 @@ boundary.
 By default the socket is `0660` group-owned by **`hive-admin`**, an
 empty group — so it's effectively **root-only** until an operator is
 explicitly granted access. Grant sudoless `hivectl` by listing login
-users in `services.hyperhive.c0re.adminUsers`; each is added to
+users in `services.hyperhive.c0re.adminUsers`; the option adds each to
 `hive-admin`, and members connect without `sudo`. The runtime dir
 `/run/hyperhive` is `0751` (traverse-only, no listing) so the group can
 reach the socket path; the socket's own `0660 hive-admin` mode gates