refactor(hive-agent): split the forge notification poller into its own crate

The poller was a `tokio::spawn` inside the `hive-agent` serve loop. It
never needed anything from that loop except a socket path, so being
in-process bought nothing and cost two things: a harness restart took
forge notifications down with it, and the whole forge/HTTP dependency
tree was linked into the serve-loop binary.

It is now `hive-forge-notify`, a per-agent daemon with its own systemd
unit, a sibling of `hive-bash-daemon` and `hive-matrix-daemon`. Same
contract as those two: it reaches the harness only by upserting todos on
the in-agent socket, and nowhere else.

The module moves verbatim (`notify.rs`) — the formatters, the activation
gates, the dedupe map and all 33 tests are unchanged. Only the socket
call sites are rewritten, onto a small local `todo_client` rather than
the harness's. That mirrors what both sibling daemons already do, and
the etiquette differs on purpose: the harness's client carries a 60s
backoff schedule sized to ride out a hive-c0re restart, which its
callers need because they have no retry of their own. This poller's two
call sites both sit inside the 30s poll loop and both treat a failure as
"leave the thread unread, try next tick", so the poll interval already
is the retry; a second backoff would only stack sleeps and delay the
rest of the batch.

The unit is `Restart=on-failure`, not `always`. An agent with no forge
account is a supported configuration and the poller reports it by
logging why and exiting 0 — under `always` that clean exit would be a
restart loop on every forge-less agent.

`forgejo-api`, `url` and `time` drop out of `hive-agent`'s dependencies
with the module.

Also corrects docs that outlived the code they described: the persisted
`forge_cursor` field is long gone (forge's own read-state is the durable
record of what has been delivered), but `docs/persistence.md` and the
`harness_state` module docs still documented it as live.

hive-agent/src/harness_state.rs

@@ -1,9 +1,8 @@
 //! File-backed harness state, split out of [`crate::events`] (which owns
 //! the live event bus + sqlite store). This module holds the runtime
-//! model/effort selection, the consolidated `hyperhive-harness.json`
-//! state file, and the `forge_notify` delivery-dedupe cursor — the
-//! persisted knobs the harness reads/writes across turns, none of which
-//! are about the live event stream.
+//! model/effort selection and the consolidated `hyperhive-harness.json`
+//! state file — the persisted knobs the harness reads/writes across
+//! turns, none of which are about the live event stream.
 
 use std::path::PathBuf;
 
@@ -84,12 +83,14 @@ fn harness_json_path() -> PathBuf {
     crate::paths::state_dir().join(HARNESS_JSON)
 }
 
-// Serialises the read-modify-write of `hyperhive-harness.json`. Two
-// harness tasks touch it in the same process — the turn loop (rate-limit
-// / needs-login / active-model) and the forge_notify poller (the
-// delivery-dedupe cursor) — writing disjoint fields, so each writer must
-// preserve the other's. The lock closes the lost-update window between a
-// writer's read and its rename.
+// Serialises the read-modify-write of `hyperhive-harness.json`. Every
+// writer merges into the existing object rather than reconstructing it,
+// so a future second writer preserves fields it doesn't own; the lock
+// closes the lost-update window between a writer's read and its rename.
+// (The forge poller used to be that second writer, for a delivery-dedupe
+// cursor. It no longer persists one — forge's own read-state is the
+// durable record — and it is a separate process now, which an
+// in-process mutex could not have serialised anyway.)
 static HARNESS_JSON_LOCK: std::sync::Mutex<()> = std::sync::Mutex::new(());
 
 /// Read the consolidated state file as a JSON object, or an empty object