docs: fix genuine passive-voice hits in docs/agent-lifecycle

Ninth batch of the ongoing write-good.Passive pass (hyperhive#4042):
read all 75 hits across agent-hierarchy.md/persistence.md/approvals.md
in context and rewrote 46 with a clearly nameable actor -- mostly
hive-c0re, a specific fn/type named right there or a sentence or two
earlier (approvals.md's numbered "Reminder delivery" list all share
hive-c0re as the established actor across three consecutive bullets),
or "the worker"/"the daemon" reused from the section's own established
subject.

Left 29 alone. Recurring buckets: predicate-adjective state pairs
("is wedged"/"is stopped", "is unaffected", "are unrelated", "is
overloaded" -- matches the established "is trusted"/"is privileged"
family), negative-capability/invariant idioms ("no X is needed",
"can't be removed/started", "no such transient was cleared"),
forward-looking design-intent statements about not-yet-built
enforcement (agent-hierarchy.md's whole "Planned topology semantics"
section leans on this: "are meant to run", "once enforcement is
finished", "will be gated"), the "audit trail, not cache" policy
invariant restated twice verbatim ("Approvals are kept forever" /
"indefinitely" -- left both alone consistently), and a config-
conditional state idiom ("when interval_seconds is set"). One more
false-positive tokenization, same bug as knowledge.md's earlier case:
persistence.md's "`config` is read-only" trips vale's "is read" match
inside the compound adjective -- not a real passive at all.

One deliberately-conservative leave: agent-hierarchy.md's "Reminder
cancellation is handled fully in-agent" had an ambiguous actor (the
in-agent socket vs. the hive-c0re source file the doc points readers
to for detail) -- left alone rather than risk a wrong attribution,
unlike the higher-confidence rewrites elsewhere in the same batch.

Verified via vale before/after: 75 -> 29 write-good.Passive hits,
exactly the 29 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/agent-lifecycle/persistence.md

@@ -65,7 +65,7 @@ power-intent registry:
   next_fire_at_unix / created_at_unix / source ("operator" or
   "approval:<id>") / cancelled_at_unix / description`. `owner`
   drives cancel-permission checks (operator vs the submitting
-  agent). Cancelled rows are tombstoned and reaped by the worker
+  agent). The worker tombstones and reaps cancelled rows
   on its next pass.
 - `scheduled_prompt_targets` — per-target state for each schedule.
   `schedule_id / target / cancelled_at_unix /
@@ -87,16 +87,16 @@ Retention:
   `hive-c0re::main`. Drops acked message rows older than 30 days
   (`acked_at IS NOT NULL`). Undelivered + delivered-but-not-acked
   rows are always kept — the harness `ack_turn`s only after a
-  successful turn, so an unacked row can still be requeued via
-  `requeue_inflight` on a crash.
+  successful turn, so `requeue_inflight` can still requeue
+  an unacked row on a crash.
 - Approvals are kept indefinitely — an audit trail. `actions::destroy`
   rows stay visible to anything that queries by id.
-- Scheduled prompts: one-shot rows are deleted on fire by the
-  worker; recurring rows live until the operator cancels them
+- Scheduled prompts: the worker deletes one-shot rows on fire;
+  recurring rows live until the operator cancels them
   (`cancel_schedule` MCP / dashboard ✗) which tombstones via
   `cancelled_at_unix`, then `reap_cancelled` drops the row on
   the next worker pass.
-- `agent_power` rows live until the agent is destroyed (one row per
+- `agent_power` rows live until the operator destroys the agent (one row per
   agent — nothing to vacuum).
 
 ### `/harness/hyperhive-events.sqlite` (per agent)
@@ -148,9 +148,9 @@ Bin-loop helpers `build_row` + `record` land each row at
 `turn_end`; writes are best-effort, a sqlite hiccup logs + lets
 the turn loop continue.
 
-A sibling `bash_commands(ts INTEGER, head TEXT)` table in the same
-file is written by the `hive-bash-daemon` (not the harness): one
-row per executed bash task recording the normalised command head -
+The `hive-bash-daemon` (not the harness) writes a sibling
+`bash_commands(ts INTEGER, head TEXT)` table in the same
+file: one row per executed bash task recording the normalised command head -
 the basename of the first real command, looking past `cd repo &&`
 prefixes, env-assignments, and prefix-runners like `sudo`/`env`. It
 backs the "favorite tools" view on the /stats page (aggregated
@@ -215,7 +215,7 @@ Three indices:
   as part of the existing hourly vacuum.
 - `(node_id)` — added by a later migration so a build log row can be
   looked up by the job-queue node it belongs to (a `hive_jobq` node is
-  immutable after insert, so the link is recorded on the log row
+  immutable after insert, so hive-c0re records the link on the log row
   instead); legacy rows predating the column keep `node_id IS NULL`.
 
 Writes are best-effort: `append_stdout` / `append_stderr` / `finish`
@@ -313,15 +313,15 @@ Under `/var/lib/hyperhive/agents/<name>/`:
     store + wake `Notify` directly rather than dialling its own socket.
     `disk_watch` raises a keyed `disk` todo when the filesystem backing
     this agent's state gets tight, naming the agent's own biggest
-    directories; the summary is bucketed and carries no raw byte
+    directories; it buckets the summary and carries no raw byte
     counts, so an unchanged situation re-upserts as `changed == false`
     and never re-wakes.
 
     Retention, same hourly `hive-agent::vacuum::run` sweep as
-    `hyperhive-events.sqlite` below: delivered (soft-deleted) reminder
-    rows are reaped 14 days after delivery, kept that long only to serve
-    the trailing-window `ReminderRollup` stats; acked todo rows are
-    reaped 30 days after acking (long enough that only a genuinely quiet
+    `hyperhive-events.sqlite` below: it reaps delivered (soft-deleted) reminder
+    rows 14 days after delivery, kept that long only to serve
+    the trailing-window `ReminderRollup` stats, and reaps acked todo rows
+    30 days after acking (long enough that only a genuinely quiet
     month triggers the "one spurious re-announcement" fallback a
     reconciled producer like `disk_watch` relies on — see `todos.rs`'s
     module doc). Un-acked todos and undelivered reminders are never
@@ -371,8 +371,8 @@ files committed via the approval flow. `.git/` carries the proposal /
 approved / building / deployed / failed / denied tag history.
 
 Under `/var/lib/hyperhive/meta/` — the swarm-wide deploy flake plus
-system-level config files. Single git repo for the whole host; every
-hive-c0re mutation that should survive a restart is committed here.
+system-level config files. Single git repo for the whole host; hive-c0re
+commits every mutation that should survive a restart here.
 Contents:
 
 - `flake.nix` — declares one `nixpkgs` input per agent + one
@@ -396,8 +396,8 @@ Contents:
   var. Absent agents have no extra capabilities.
 - `resource-limits.json` — per-agent container resource overrides
   (`{ "sock": { "cpu_quota": "400%", "memory_max": "8G" } }`).
-  Written by `resource_limits::set_limits`; read where the systemd
-  drop-in is generated (`lifecycle::write_dropins`), **not** injected
+  Written by `resource_limits::set_limits`; read where
+  `lifecycle::write_dropins` generates the systemd drop-in, **not** injected
   into the container — these are host-side caps on the container, so
   the capped party never sees or sets them. Fallback is per *field*:
   an absent file, absent agent, or absent field falls back to the
@@ -411,7 +411,7 @@ The root agent has the meta dir RO-mounted at `/meta/`.
 
 The `.meta-migration-done` marker no longer exists: the
 one-shot container repoint it guarded has been removed, since
-containers are rendered onto `meta#<n>` at creation. A stale
+hive-c0re renders containers onto `meta#<n>` at creation. A stale
 marker file left over from an older hive is inert and can be
 deleted.
 
@@ -426,8 +426,8 @@ an agent's state. The mechanics, for completeness:
 - `PURG3` wipes `/var/lib/hyperhive/{agents,applied}/<name>/` — the
   union of everything `DESTR0Y` left behind.
 
-The root/bootstrap agent's specialness is implemented as a soft policy
-guard in `actions::destroy` that refuses to destroy it, backstopped by
+`actions::destroy` implements the root/bootstrap agent's specialness as a soft policy
+guard that refuses to destroy it, backstopped by
 `auto_update::ensure_root_agent`, which recreates it on the next
 hive-c0re startup if it's ever absent (bypassing the approval queue,
 as required infrastructure) — so even without the guard, destroying it
@@ -435,7 +435,7 @@ would only be transient.
 
 ### btrfs subvolumes for `/var/lib/hyperhive/agents/<name>`
 
-On a btrfs host, a brand-new agent's state root is created as a
+On a btrfs host, `lifecycle::ensure_agent_state_subvolume` creates a brand-new agent's state root as a
 **btrfs subvolume** instead of a plain directory (progressive
 enhancement — see the #1762 lane). This is a no-op fallback on
 non-btrfs hosts and for any agent whose root already exists, so
@@ -443,7 +443,7 @@ nothing is automigrated: existing agents keep their plain dirs
 until an explicit opt-in upgrade.
 
 - **Creation:** `lifecycle::ensure_agent_state_subvolume` runs before
-  the per-agent subdirs are created (spawn / rebuild / InitConfig).
+  hive-c0re creates the per-agent subdirs (spawn / rebuild / InitConfig).
   It skips the work when the root already exists; otherwise it asks
   hive-priv (`EnsureAgentSubvolume`) to `btrfs subvolume create` the
   root when the FS is btrfs (`statfs` magic gate) and chown it to the
@@ -475,8 +475,8 @@ Only present on the one host running
 `services.hyperhive.deploy.swarm-controller.enable`. systemd `StateDirectory=`,
 so it survives restarts and redeploys.
 
-- `webhook-secret` — the HMAC key the swarm's forge webhooks are signed
-  with. **Keep it.** It's handed to Forgejo when a hook is registered,
+- `webhook-secret` — the HMAC key Forgejo signs the swarm's forge webhooks
+  with. **Keep it.** It's handed to Forgejo when swarm-controller registers a hook,
   so replacing the file means every subsequent delivery fails
   verification until the hook is re-registered with the new value. It's
   generated automatically on first start; there is nothing to configure.
@@ -565,8 +565,8 @@ avatar (see below).
 
 ### matrix avatar (set by the daemon over the live Client)
 
-The agent icon (`hyperhive.icon`, an SVG) is published as each matrix
-account's profile avatar by `hive-matrix-daemon` itself
+`hive-matrix-daemon` itself publishes the agent icon (`hyperhive.icon`, an SVG) as each matrix
+account's profile avatar
 (`hive-matrix-mcp::client::sync_avatar`), not a separate oneshot. After
 the daemon builds + restores an account's `Client` (authenticated,
 pointed at that account's resolved homeserver), it calls matrix-sdk's
@@ -574,7 +574,7 @@ pointed at that account's resolved homeserver), it calls matrix-sdk's
 `avatar_url`. Because it reuses the live Client, there is no hardcoded
 homeserver URL, no token re-read, and no token-file globbing: the daemon
 already iterates every configured + dashboard-discovered account in its
-bring-up loop, so the avatar is set for **every** account.
+bring-up loop, so it sets the avatar for **every** account.
 
 Nix rasterizes the SVG to a 512x512 PNG at build time (`iconPng`, via
 librsvg) and forwards its store path as `HIVE_ICON_PNG` on the daemon
@@ -588,6 +588,6 @@ skips the upload when unchanged, because every upload mints a fresh
 re-uploading identical bytes is timeline spam. A dashboard-provisioned
 account gets its avatar when the `systemd.paths.hive-matrix-daemon` token
 watcher restarts the daemon (which re-runs the per-account bring-up), so
-no separate avatar trigger is needed. Avatar failures are swallowed
+no separate avatar trigger is needed. The daemon swallows avatar failures
 (logged, non-fatal) so they never break account bring-up or sync.