docs: name the actor instead of the vague 'we'/'our'

Per mara's ruling on hyperhive#4041 (Microsoft.We): keep the rule enabled,
same treatment as the 'backend' rewrites. Traced all 21 genuine hits (4
gateway.md 'Let's Encrypt' hits are a substring-match false positive, left
alone) to their actual referent: some name a specific component already
established nearby in the same doc (forge_notify, hive-github-notify's
poller, hive-forge, hive-agent/the harness, colors.css, the dashboard),
others were pure filler that adds nothing once dropped.

docs/integrations/forge.md

@@ -277,7 +277,7 @@ The one gap the timestamp cut leaves: a genuine comment posted **within
 `NEW_ITEM_TOLERANCE_SECS` of the merge** bumps `updated_at` close enough
 to `closed_at` that `state_change_is_current` returns `true` — so it takes
 the state-change path, dropping its body. Best of both worlds:
-on the merge/close path we fetch the `latest_comment_url` comment and, when
+on the merge/close path `forge_notify` fetches the `latest_comment_url` comment and, when
 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
@@ -286,7 +286,7 @@ pre-merge last comment the subject keeps — append it as a
 and the racing comment. `forge_notify` leaves the kept pre-merge comment (created before
 `closed_at`) off, drops a self-authored racing comment (don't
 echo the agent's own write), and appends nothing for a missing/unparseable `created_at`/
-`closed_at` (conservative — only surface a comment we can
+`closed_at` (conservative — only surface a comment it can
 positively place after the close). Cost: one extra comment fetch on
 merge/close notifications, acceptable given how rare they are.
 
@@ -300,7 +300,7 @@ 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`. `forge_notify` labels anything later `activity on <kind>`
-— neutral and non-misleading, since we can't cheaply say _what_ the
+— neutral and non-misleading, since it can't cheaply say _what_ the
 activity was without an extra reviews fetch. Missing/unparseable
 timestamps default to `new` (preserve prior behavior rather than mask a
 genuine new item). A small dependency-free

docs/integrations/github.md

@@ -128,10 +128,10 @@ application/vnd.github+json`, `X-GitHub-Api-Version` and a
   header: `x-ratelimit-remaining` near 5000 is an authenticated user,
   near 60 is anonymous.
 - **GitHub sets the cadence.** It returns `X-Poll-Interval` (60s in
-  practice, slower than our own tick) and rate-limits callers who ignore
-  it, so the loop re-arms to the server's interval whenever that's
-  _slower_ than ours. A hint faster than our own tick isn't a reason to
-  poll harder.
+  practice, slower than the poller's own tick) and rate-limits callers who
+  ignore it, so the loop re-arms to the server's interval whenever that's
+  _slower_ than the poller's. A hint faster than the poller's own tick
+  isn't a reason to poll harder.
 
 ⚠️ **This needs the `notifications` scope on the PAT.** A token minted
 for `gh` + `git push` typically carries `repo` only, which is enough to