feat(#3255): receive swarm-wide forge webhooks in the controller

A Forgejo webhook has one target_url, so every hive registering the same
swarm-wide hooks is last-writer-wins rather than idempotent. The controller
is the only swarm-wide thing in the deployment, so it becomes the receiver.

It verifies the HMAC and treats the payload as opaque bytes keyed by the hook
kind in the URL path; it deliberately does not parse the payload, because the
hives' existing handlers already decide what a delivery means.

Nothing is registered against the endpoint yet. The replacement path is built
and observable before anything takes the old one away, so the swarm's single
target_url never points at a receiver that forwards nowhere.

swarm-controller/Cargo.toml

@@ -38,6 +38,12 @@ problem_details = { version = "0.9.0", features = ["axum"] }
 # same shape `hive-c0re/src/job_queue/scheduler.rs` uses over its own graph.
 hive-jobq.workspace = true
 hive-jobq-wire.workspace = true
+# The forge webhook HMAC (`webhook.rs`). Kept in this crate rather than
+# shared with hive-c0re's equivalent: c0re's copy is scheduled to be deleted
+# with its webhook routes once registration moves here, so the second holder
+# is departing, not arriving — see that module's docs.
+hmac.workspace = true
+sha2.workspace = true
 # Validates `POST /api/agents`' `name` before it becomes `agent`/`repo`
 # everywhere downstream — see `create_agent`'s doc comment for why this is
 # defense-in-depth, not the only gate (per an argus review finding).