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

Seventh batch of the ongoing write-good.Passive pass (hyperhive#4042):
read all 65 hits across jobq.md/ci.md/observability.md/coordinator.md
in context and rewrote 41 with a clearly nameable actor -- mostly
hive-c0re, nix/the nix module, the harness, or a specific fn/type
named right there or nearby (coordinator.md's node-inventory table
and DAG-shape descriptions name concrete Rust items constantly, so
the actor is almost always sitting in the same sentence).

Left 24 alone: predicate-adjective-copula state descriptions ("is
stuck", "is gone", "is unaffected", "is done", etc. -- the largest
recurring bucket this batch, especially in observability.md's
scope/status descriptions), negative-capability idioms ("no X is
needed/left", "X can't be written down"), the established "is
tracked as a follow-up" idiom, a firewall-shorthand notation
("bridge->127.0.0.0/8 is dropped") where rewriting would break the
compact rule-like format, a CLI-flag "(repeatable)" annotation ("May
be repeated"), a Rust type-signature fact ("`moves` is typed ..."),
a hypothetical/counterfactual maintenance-burden clause, a
readiness-condition list ("a node is ready when ... every dep is
satisfied"), and one deliberately-parallel idiom pair
("When OTEL is enabled" used identically twice as a section-opening
convention -- fixing one would break the parallelism, not the
opposite).

One self-caught regression: an early attempt to fix "used by every
`Reconcile` node's start action" (a reduced participial clause, not
flagged) into "is used by every `Reconcile` node's start action"
introduced a brand-new flagged passive. Caught by the post-edit vale
count (expected 65->24, got 65->25) not matching, same discipline as
the docs/turn-loop batch's tail-truncation catch -- re-ran with
active voice instead ("Every `Reconcile` node's start action uses
this fallback").

Verified via vale before/after: 65 -> 24 write-good.Passive hits,
exactly the 24 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/scheduler/ci.md

@@ -56,8 +56,8 @@ never writes to that status slot. Reproduced with three dispatches on one
 PR over 20+ minutes, all genuinely green, the PR's own status unmoved
 throughout. **Always re-check `pr-status` after a dispatch and believe
 what it says — don't push a commit just to unwedge it, that's the
-empty-commit anti-pattern this verb exists to avoid.** If the code is
-verified green (`hive-forge ci-log --run <n> --job 0`, verdict is the
+empty-commit anti-pattern this verb exists to avoid.** If `hive-forge
+ci-log --run <n> --job 0` shows the code green (verdict is the
 last line) but the status is stuck, ask the operator to select "rerun" in
 the forge web UI — it's CSRF-gated, so only they can do it.
 
@@ -74,8 +74,8 @@ sh scripts/check-issue-refs.sh  # tracker-tag lint
 sh scripts/check-comment-blocks.sh  # comment-block lint
 ```
 
-A git pre-push hook that automates the two lint checks is provided at
-`scripts/pre-push`. Install it once per clone:
+`scripts/pre-push` provides a git pre-push hook that automates the two
+lint checks. Install it once per clone:
 
 ```sh
 ln -sf ../../scripts/pre-push .git/hooks/pre-push
@@ -112,13 +112,13 @@ it and runs it out of band, so a slow forge or core-token never delays the
 container's start. Gotcha: don't gate the container's own start on a forge
 round-trip (a host-side unit that did this could exceed the nspawn start
 timeout and trip a restart loop) — registration must stay something
-hive-c0re drives after the container is already up. The core admin token is
-held only by hive-c0re on the host; only the runner registration token
+hive-c0re drives after the container is already up. hive-c0re holds the
+core admin token only on the host; only the runner registration token
 reaches the container.
 
 ### hive-c0re side (`forge/ci_runner.rs`, run during the startup sweep)
 
-Gated on `HYPERHIVE_FORGE_CI_ENABLED` (the nix module sets it on `hive-c0re.service` when `deploy.forgejo.ci.enable`). Best-effort — failures are logged and never abort the sweep; a healthy runner is never restarted.
+Gated on `HYPERHIVE_FORGE_CI_ENABLED` (the nix module sets it on `hive-c0re.service` when `deploy.forgejo.ci.enable`). Best-effort — hive-c0re logs failures and never aborts the sweep; a healthy runner is never restarted.
 
 1. If `.runner` exists at `/var/lib/nixos-containers/hive-ci/var/lib/gitea-runner/hive/.runner`, validate its id against `GET /api/v1/admin/runners/{id}` with the core admin token:
    - **200**: still registered — done, no restart.
@@ -141,7 +141,7 @@ When `deploy.forgejo.ci.enable` is set, hive-c0re autoseeds an
 `uses: actions/checkout@vN` steps resolve entirely on loopback — no
 external DNS on the CI critical path.
 
-The mirror is seeded by **hive-c0re** itself during its forge
+**hive-c0re** itself seeds the mirror during its forge
 provisioning sweep (`forge/repos.rs::ensure_mirrors`). The nix module
 forwards the effective mirror list as `HYPERHIVE_FORGE_MIRRORS` in the
 `hive-c0re` service environment (JSON-encoded `[{upstream, dest}]`
@@ -159,11 +159,11 @@ services.hyperhive.deploy.forgejo.mirrors = [
 ];
 ```
 
-Each entry is created as a real Forgejo pull-mirror — not a one-off
+hive-c0re creates each entry as a real Forgejo pull-mirror — not a one-off
 clone. Forgejo re-syncs the mirror on every pull (`git-upload-pack`
 request), so a DNS blip during that sync will propagate back to the
-runner as a hard `git clone` failure. The
-`<owner>` org in `dest` is autocreated. Keep mirror dests out of the
+runner as a hard `git clone` failure. hive-c0re
+autocreates the `<owner>` org in `dest`. Keep mirror dests out of the
 hive-c0re-managed namespaces (`config/`, `shared/`, `agents/`, `core/`)
 to avoid provisioning collisions.
 
@@ -173,7 +173,7 @@ to avoid provisioning collisions.
 
 ### What unsandboxed builds mean
 
-nspawn containers can't create user-namespaces, so `nix.settings.sandbox-fallback = true` is set in the container. This means every `nix build` (and `nix flake check`) runs **without a build sandbox** — the build process has full access to the container filesystem, network, and any bind-mounts during the build phase.
+nspawn containers can't create user-namespaces, so the module sets `nix.settings.sandbox-fallback = true` in the container. This means every `nix build` (and `nix flake check`) runs **without a build sandbox** — the build process has full access to the container filesystem, network, and any bind-mounts during the build phase.
 
 A malicious `default.nix` or build script in a PR can therefore:
 
@@ -235,15 +235,15 @@ following to your host config:
 ```
 
 **Measure a collection on your own hosts before relying on that stagger.**
-`randomizedDelaySec` spreads the _start_, not the run, and the run is dominated
-by the sweep over unused `.links` entries — which scales with the size of the
+`randomizedDelaySec` spreads the _start_, not the run, and the sweep over
+unused `.links` entries dominates the run — which scales with the size of the
 store, not with what this collection deletes. On a large store it can take most
 of an hour, so two hosts both set to `daily` may overlap however much jitter you
 give them. `journalctl -u nix-gc.service` reports each run's wall clock.
 
 **Remote builders:** if CI dispatches builds to a remote builder (for example via
 `nix.buildMachines` / `ssh-ng://`), the build outputs land in _that host's_
-store, so the same GC config should be applied wherever the builder runs —
+store, so apply the same GC config wherever the builder runs —
 GC on the coordinator host won't reclaim space on the builder.
 
 ⚠️ Two stores also means the temp-root protection above **doesn't span