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/observability.md

@@ -87,10 +87,10 @@ turn-stats rather than from a metric label.
 
 ## Options reference
 
-Every `services.hyperhive.otel.*` option's full type/default/description/
-example is generated straight from the nix module (`nix/host-modules/
-otel.nix`) into [`/options/`](/options/) (host options — `nix build
-.#docs-host` for a local render). That page is kept honest by the build in a
+The nix module (`nix/host-modules/otel.nix`) generates every
+`services.hyperhive.otel.*` option's full type/default/description/
+example straight into [`/options/`](/options/) (host options — `nix build
+.#docs-host` for a local render). The build keeps that page honest in a
 way a hand-copied version here can't be, so it's the reference, not this
 doc. What follows is what a flat per-option listing can't express: the
 two-tier architecture, the security model, and how the options interact.
@@ -130,7 +130,7 @@ the local deployment stops testing.
 **`endpoint` keeps meaning "where telemetry goes upstream."** Neither tier
 redefines it — the agent-facing value is _derived_
 (`http://<bridgeIp>:<collector.port>`), so an existing deployment's `endpoint`
-keeps working unchanged. The bridge port is contributed to `exposeHostPorts`
+keeps working unchanged. The otel module contributes the bridge port to `exposeHostPorts`
 automatically; there is nothing to open by hand.
 
 ### Authenticated ingest
@@ -162,7 +162,7 @@ swarm tier and no metrics appearing for that hive.
 `otel.protocol` (`grpc` → the gRPC exporter, otherwise OTLP/HTTP), and the gRPC
 exporter takes an _address_: `https://host/path` is a legal
 `OTEL_EXPORTER_OTLP_ENDPOINT` for HTTP but fails as gRPC with _"missing port in
-address"_. The collector's config is validated at build time, so a mismatch is
+address"_. nix validates the collector's config at build time, so a mismatch is
 a build error naming the reason rather than telemetry silently going nowhere.
 
 ## Network access
@@ -186,8 +186,8 @@ contributes the collector's port and derives the agent-facing endpoint itself.
 
 ## Built-in resource labels
 
-The OTLP variables (`OTEL_EXPORTER_OTLP_ENDPOINT`, `_PROTOCOL`,
-`OTEL_RESOURCE_ATTRIBUTES`, the temporality preference) are set **container
+The harness sets the OTLP variables (`OTEL_EXPORTER_OTLP_ENDPOINT`, `_PROTOCOL`,
+`OTEL_RESOURCE_ATTRIBUTES`, the temporality preference) **container
 wide** — in systemd's `DefaultEnvironment` and in `/etc/profile` — so every
 process in an agent container exports to the hive's collector without any
 per-tool wiring. That covers Claude Code, `hive-metric`, and anything you run
@@ -203,8 +203,8 @@ automatically:
 | `hive`         | hive display name (`services.hyperhive.hiveName`)            |
 | `swarm`        | swarm display name (`services.hyperhive.swarm.name`, if set) |
 
-Additional labels can be appended via `extraResourceAttributes` (see option
-reference above); custom per-data-point labels can be passed with
+Append additional labels via `extraResourceAttributes` (see option
+reference above); pass custom per-data-point labels with
 `hive-metric --labels` (see below).
 
 ## Host-emitted container-resource metrics (hive-c0re)
@@ -219,7 +219,7 @@ Emitted via the OpenTelemetry Rust SDK, using the
 [semconv `container.*`](https://opentelemetry.io/docs/specs/semconv/system/container-metrics/)
 metric names + the standard `container.name` attribute where a spec metric
 exists, so off-the-shelf OTEL/Grafana container dashboards work. Resource
-`service.name = hyperhive-c0re`; each data point is tagged `container.name`
+`service.name = hyperhive-c0re`; hive-c0re tags each data point `container.name`
 (= the `h-<agent>` machine) and the hive `agent` label:
 
 | Metric                              | Unit | Kind    | Source                                                                                                      |
@@ -266,8 +266,8 @@ same container-wide `OTEL_RESOURCE_ATTRIBUTES` as everything else in this
 section — nothing extra to configure. Cadence follows
 `HYPERHIVE_OTEL_METRIC_INTERVAL_MS` (default 60s, same variable + default as
 `hive-c0re`'s container-resource export above) — that only controls how often
-the batched points are flushed to the collector, not how often they're
-recorded (every turn, always).
+the harness flushes the batched points to the collector, not how often it
+records them (every turn, always).
 
 ## Hive-scoped metrics (hive-c0re)
 
@@ -283,7 +283,7 @@ distinguishable from "this hive is gone." Select them with
 | `hyperhive.hive.degraded` | `1`  | gauge | `1` while the hive reports itself unhealthy — the same verdict `/health/ready` gives and the swarm status view shows |
 | `hyperhive.hive.warnings` | `1`  | gauge | how many warnings are currently raised, split by a `level` attribute (`warn`, `crit`)                                |
 
-Both levels are reported every cycle, `0` included, so a healthy hive is
+hive-c0re reports both levels every cycle, `0` included, so a healthy hive is
 visible as zeros rather than as missing series.
 
 `hyperhive.hive.degraded` is what a dashboard should alert on: it's
@@ -300,8 +300,8 @@ Same cadence, transport and resource labels as the container metrics above.
 "global/system" hook, not scoped to any one org or repo) and counts commit
 and push activity as deliveries arrive — occurrence-driven, not polled.
 Forgejo's own native `/metrics` endpoint has no equivalent: it exposes
-counts of durable rows (issues, comments, repos), and neither a commit nor a
-push is stored anywhere as a row to count.
+counts of durable rows (issues, comments, repos), and Forgejo doesn't
+store either a commit or a push anywhere as a row to count.
 
 | Metric                       | Unit | Kind    | Attributes          |
 | ---------------------------- | ---- | ------- | ------------------- |
@@ -314,9 +314,9 @@ when the delivery actually carries commits. Same enable signal (`OTEL_EXPORTER_O
 (`HYPERHIVE_OTEL_METRIC_INTERVAL_MS`) and `HYPERHIVE_OTEL_EXTRA_RESOURCE_ATTRIBUTES`
 resource-attribute channel as `swarm-controller`'s other OTEL exporter (its
 `hive-jobq-metrics`-backed job-graph rollup, undocumented here — see that
-crate's own doc comment) — `service.name = swarm-controller` is set
-directly rather than read from the container environment, since
-`swarm-controller` is a standalone daemon, not a per-agent harness process.
+crate's own doc comment) — `swarm-controller` sets `service.name =
+swarm-controller` directly rather than reading it from the container
+environment, since it's a standalone daemon, not a per-agent harness process.
 
 ## Agent-emitted custom metrics (`hive-metric`)
 
@@ -340,7 +340,7 @@ hive-metric <name> <value> [--type counter|gauge] [--temporality delta|cumulativ
   reports the running total, which a stateless one-shot CLI can't track
   itself).
 - `--labels key=value` — extra per-data-point labels. May be repeated.
-  The resource labels (agent, hive, swarm, service.name) are inherited
+  `hive-metric` inherits the resource labels (agent, hive, swarm, service.name)
   automatically from `OTEL_RESOURCE_ATTRIBUTES` — don't re-specify them.
 
 ### Examples
@@ -366,12 +366,12 @@ with an informative error message. No silently dropped metrics.
 
 `hive-metric` always uses **OTLP HTTP/JSON** (`application/json` POST to
 `$OTEL_EXPORTER_OTLP_ENDPOINT/v1/metrics`), regardless of the
-`OTEL_EXPORTER_OTLP_PROTOCOL` setting. Auth headers from
-`OTEL_EXPORTER_OTLP_HEADERS` are forwarded verbatim.
+`OTEL_EXPORTER_OTLP_PROTOCOL` setting. `hive-metric` forwards auth headers from
+`OTEL_EXPORTER_OTLP_HEADERS` verbatim.
 
 ## Metrics temporality
 
-OTEL export is configured with **cumulative** temporality by default
+The harness configures OTEL export with **cumulative** temporality by default
 (`OTEL_EXPORTER_OTLP_METRICS_TEMPORALITY_PREFERENCE=cumulative`),
 overriding Claude Code's default of DELTA. This avoids silent metric drops in
 Prometheus-family backends (including Grafana LGTM / Mimir) that don't ship a