docs: fix write-good.So/ThereIs/Weasel lint findings

Fixes the "obvious ones first" slice of #4042 (mara: do the obvious
ones first) -- 81 hits across write-good.So, write-good.ThereIs, and
write-good.Weasel, all in docs/. Each is a genuine sentence rewrite
(lead with the real subject instead of "There is/are", drop a
sentence-initial "So ", replace a vague intensifier), not a blind
regex substitution -- read every hit in its real file context before
touching it.

3 of the 81 hits were in CI-generated CLI docs (docs/tools/{hivectl,
swarmctl,forge}-cli.md) -- fixed at the clap #[arg(...)]/doc-comment
source in hivectl/src/cli.rs, swarmctl/src/main.rs, and
hive-forge/src/verbs/repo_add_collaborator.rs, then regenerated via
each crate's `markdown-docs` subcommand so CI's freshness check stays
green.

Verified: fresh vale re-run shows 0 remaining So/ThereIs/Weasel hits
and no new hits introduced (983->982, exactly the one incidental fix
this pass also picked up at docs/scheduler/observability.md:48).
cargo fmt --check and clippy clean on the three touched crates.

Remaining write-good backlog (Passive: 726, TooWordy: 207) is
judgment-heavy and left for a follow-up slice of #4042, not bulk-
rewritten here.

docs/integrations/forge.md

@@ -117,7 +117,7 @@ read on forge straight away (`PATCH /notifications/threads/{id}`). The
 broker inbox is the durable work queue now — each delivered wake is a
 sqlite row with its own ack lifecycle — so the forge unread flag no
 longer needs to track whether the agent has _processed_ a
-notification. Clearing it on delivery keeps forge's unread set **tiny
+notification. Clearing it on delivery keeps forge's unread set **small
 by construction**: at rest it holds only threads that failed to
 deliver plus whatever arrived since the last 30s poll.
 
@@ -140,7 +140,7 @@ wake already carries the notification body, so _delivery is the read_.
 An agent that wants the full thread still runs `hive-forge comments` /
 `view`.
 
-**In-process dedupe (tiny, ephemeral).** A single-process map (thread
+**In-process dedupe (small, ephemeral).** A single-process map (thread
 id → last-delivered `updated_at`) guards the narrow window where a
 mark-read call _transiently fails_ and the thread reappears unread in
 the next poll before its `updated_at` bumps — so a flaky PATCH doesn't
@@ -165,7 +165,7 @@ The poller starts disabled and stays that way for any of:
 - Initial client construction fails (the typed `forgejo-api` client
   for the API calls, or the plain reqwest client kept for the
   best-effort enrichment fetches of server-provided subject URLs;
-  both extremely unlikely; treated as fatal-to-the-task only).
+  both unlikely; treated as fatal-to-the-task only).
 
 Disabled = the spawned task returns immediately. All other failure
 modes (HTTP errors, parse errors, mark-read failures) are
@@ -260,7 +260,7 @@ path. But a merged/closed subject **keeps** its `latest_comment_url` set,
 so a just-merged PR that had any prior discussion would route to the
 comment path and render `[comment on PR]` (with a stale pre-merge comment
 body) instead of `[PR merged]` — the agent never learns its PR merged.
-So when the notification IS the merge/close transition — its
+When the notification IS the merge/close transition — its
 event time (`updated_at`) is within `NEW_ITEM_TOLERANCE_SECS` of the
 subject's `closed_at` (set for both `merged` and `closed`) — the
 state-change path wins even with a comment url present
@@ -281,7 +281,7 @@ its `created_at` is strictly **after** the subject's `closed_at`
 (`comment_is_after_close`) — that is it raced the merge rather than being the
 pre-merge last comment the subject keeps — append it as a
 `comment by <author>: <excerpt>` block before the meta suffix
-(`fresh_post_close_comment_tail`). So the wake carries **both** `[PR merged]`
+(`fresh_post_close_comment_tail`). The wake carries **both** `[PR merged]`
 and the racing comment. The kept pre-merge comment (created before
 `closed_at`) is left off, a self-authored racing comment is dropped (don't
 echo the agent's own write), and a missing/unparseable `created_at`/
@@ -295,7 +295,7 @@ A review submitted with **no body** carries no `latest_comment_url`,
 so it misses the comment path and lands on the state-change path with
 `state == "open"` — exactly like a freshly opened PR. Labeling that
 `new PR` is misleading: agents dismiss it as a duplicate of the
-original open notification and miss the review. So the `open`
+original open notification and miss the review. The `open`
 state only earns the `new <kind>` label when the notification's event
 time (`updated_at`) is within `NEW_ITEM_TOLERANCE_SECS` (120s) of the
 subject's `created_at`. Anything later is labeled `activity on <kind>`