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

Sixth batch of the ongoing write-good.Passive pass (hyperhive#4042):
read all 52 hits across knowledge.md/github.md/matrix.md/forge.md in
context and rewrote 39 with a clearly nameable actor -- mostly
hive-c0re, forge_notify, or a specific fn named right there or a
sentence or two earlier. forge.md's notification poller is the
densest yet (19/20 hits rewritten): forge_notify is established as
the section's sole actor early and reused throughout, the shape
that's produced the highest catch rates all along.

Left 13 alone: the "no X is needed" negative-capability idiom (x2),
a container-lifecycle state descriptor ("when container is stopped"),
a false-positive tokenization ("read-only" split across a line wrap,
vale matches "is read" inside it -- not a real passive at all), the
"X can't be Yed" idiom, a generic "before the ids are minted" timing
clause with no natural actor to name, a room-join policy-state
descriptor, an "is enabled"/"is trusted" pair describing a config/
trust state (predicate-adjective-copula bucket, same family as
"is privileged" from an earlier batch), three "**X is required**"
bolded requirement-list labels (structural convention, not really
mid-sentence passives), and a contrastive "are shared" clause
mirrored against an active sibling clause exactly like
claude-invocation.md's "everything else is shared" from the
turn-loop batch -- left alone there for the same reason.

One sibling-inconsistency catch worth flagging: forge.md's merge-
racing-comment paragraph had two passive clauses ("is left off",
"is dropped") sitting next to a third, already-active clause
("appends nothing") in the same three-item parallel list -- rewrote
all three under one active subject (forge_notify) for consistency.

Verified via vale before/after: 52 -> 13 write-good.Passive hits,
exactly the 13 left alone above; error count and other warning
categories unchanged (still on TooWordy since #4097 hasn't merged to
this branch yet). Re-read every changed line in full surrounding
context after editing, matching the diff to intent before running
the final vale check.

docs/integrations/github.md

@@ -7,13 +7,13 @@ HTTPS, both authenticated by an operator-supplied personal access token
 
 Provisioning is UI-driven, mirroring the dashboard side of the
 [matrix account](matrix.md) flow: paste a PAT into the agent's credentials
-tab and it works. No per-agent nix declaration, no rebuild — the token is
-injected into the agent's state dir out of band.
+tab and it works. No per-agent nix declaration, no rebuild — hive-c0re
+injects the token into the agent's state dir out of band.
 
 ## Enabling
 
 The integration is **on by default** for every agent (`hyperhive.github.enable
-= true`), inert until a PAT is provisioned. No per-agent declaration is
+= true`), inert until the operator provisions a PAT. No per-agent declaration is
 needed — an agent gains GitHub by having a PAT written to its token
 file.
 
@@ -81,8 +81,8 @@ When enabled, the container gets:
 Both scripts read the token from `<state>/github-token` **at invocation
 time**, so a PAT written (or rotated) mid-session takes effect immediately
 — no container rebuild or restart. Until the file exists, `gh` / `git push`
-fail unauthenticated. The token path is baked into the scripts at
-build time (not read from an env var), because claude's Bash tool runs in a
+fail unauthenticated. The build bakes the token path into the scripts
+(rather than reading it from an env var), because claude's Bash tool runs in a
 minimal environment that wouldn't carry one.
 
 ### Notifications
@@ -108,13 +108,13 @@ logs why and exits 0, which is why it's `Restart = on-failure` and
 never `always` — a clean exit on a PAT-less agent must not become a
 restart loop.
 
-Forgejo's notifications API is modelled on GitHub's, so one tolerant
+Forgejo models its notifications API on GitHub's, so one tolerant
 parse serves both: `id`, `repository.full_name`,
 `subject {title,url,latest_comment_url}` and `updated_at` line up field
-for field. The two real differences are absorbed by lenient
-deserializers — GitHub sends the thread id as a _string_ where Forgejo
-sends a number, and says `PullRequest` where Forgejo says `Pull`. Todo
-keys are prefixed `gh:<id>` so a github thread id can't collide with a
+for field. Lenient deserializers absorb the two real differences —
+GitHub sends the thread id as a _string_ where Forgejo
+sends a number, and says `PullRequest` where Forgejo says `Pull`.
+`hive-github-notify` prefixes todo keys `gh:<id>` so a github thread id can't collide with a
 forge one.
 
 Two host differences worth knowing before touching this code: