feat(#2642): a github.com notification poller alongside the forge one

hive-forge-notify grows a second binary, hive-github-notify. The two
share the notification half of the job — tolerant parse, classification,
formatting, dedupe, todo delivery — and nothing else: each binary owns
its host's protocol outright.

Two binaries rather than one multi-source daemon, and rather than a
cargo feature. A feature would unify across the workspace and cost every
crate its build cache. Two binaries keep the decision in nix: forge.nix
installs the forge unit, github.nix installs the github one under
hyperhive.github.enable, so a hive built without that module has no
github poller in its closure at all — GitHub access is separable (a
tier, a policy boundary), not merely switched off. Both binaries ship
from the existing derivation, so packages.nix is untouched.

The split is real at the code level too, not just at the unit level.
source.rs is a trait; the impls live in the binaries that use them, so
neither binary links the other's protocol code and the library names no
host at all. The forge-only assigned-issue rollup moves into the forge
binary for the same reason: it asks the forge what is assigned to this
agent, which is not a notification-protocol concern.

At runtime the github unit needs a PAT at <state>/github-token, the same
dashboard-provisioned token the gh wrapper and the git credential helper
already use. No PAT: it logs why and exits 0, which is why the unit is
Restart=on-failure and not always.

Forgejo's notifications API is modelled on GitHub's, so one tolerant
parse serves both — the differences (string thread ids, PullRequest vs
Pull) are absorbed by lenient deserializers rather than a second parse
path. Thread ids normalise to String at the parse boundary; they are
only ever opaque keys. Todo keys gain a per-source prefix so the two
hosts cannot collide, and the forge's is deliberately empty to keep
existing forge todo keys stable across the deploy that lands this.

The github loop honours the server's X-Poll-Interval, re-arming only
when the server asks for a slower cadence than ours; the hint is read
before the status check, because it arrives on error and empty pages too
and that is exactly when it matters. Reading the notification stream
needs the notifications scope on the PAT, which a token minted for push
access typically lacks; the failure mode is silence, so docs/github.md
says so explicitly.

docs/forge.md

@@ -85,14 +85,24 @@ reqwest.
 
 ## Notification poller (`hive-forge-notify/src/notify.rs`)
 
-Its own long-running per-agent daemon (`hive-forge-notify`, one systemd
-unit, a sibling of `hive-bash-daemon` / `hive-matrix-daemon`) — it used
+Its own long-running per-agent daemon (`hive-forge-notify`, a sibling of
+`hive-bash-daemon` / `hive-matrix-daemon`) — it used
 to be a background task inside the `hive-agent` serve loop. Polls
 `GET /api/v1/notifications?all=false` every 30 seconds (Forgejo's
 unread-only filter), formats each notification as a broker
 `Wake { from: "forge" }` message, and delivers it to the agent's own
 inbox so claude's normal turn loop picks it up.
 
+The crate builds a second, independent binary for a different host — see
+[github.md](github.md#notifications).
+
+The host-specific calls — list unread, mark read, resolve own login —
+live behind `Source` in `hive-forge-notify/src/source.rs`;
+classification, formatting, dedupe and todo delivery are shared. Todo
+keys here are the bare thread ids, and must stay that way: renaming them
+would orphan every in-flight forge todo on the first restart after a
+deploy.
+
 ### Mark-read on delivery
 
 On a **successful** broker delivery, `forge_notify` marks the thread