config PRs: remove the hive's config-PR webhook, poll and core merge

An operator's merge on the forge deploys a config PR through
swarm-controller's DeployRequest{rev}. The hive-side path that queued a
MergeConfigPr approval and merged the PR as `core` goes:

- the `/webhook/config-pr` receiver, its HMAC secret, the WebhookRegister
  boot node and the org-hook registration; the hive vhost's `/webhook/`
  location
- the 5-minute config-PR poll
- ApprovalKind::MergeConfigPr, its dashboard card, and the deploy DAG it
  drove (DeployWindow, MergeVerify, DeployApply, FinalizeDeploy,
  DeployTail), with verify_commit, the two-phase meta deploy, rollback
  refs, the PR-failure comment and forge/pr_merge.rs
- `fetched_sha`, `sha_short`/`pr_number` on approval events, and
  `sha`/`tag` on HelperEvent::ApprovalResolved: only the merge path set
  them

`config_repo`, `merged_pr_for_commit` and `post_pr_comment` move to
forge/pr_comment.rs for the merged-rev deploy's refusal comment.
Approvals v5 drops stored `merge_config_pr` rows; a test reopens a v4
database holding them.

Closes #4850

swarm-controller/src/webhook.rs

@@ -10,16 +10,6 @@
 //! the payload and emits a semantic message — *the knowledge repo changed*,
 //! *deploy agent X at rev Y* — addressed to the hives that need it. One place
 //! decides what a forge payload means, so no hive re-derives it.
-//!
-//! Receipt is all that is wired today: the payload is opaque bytes keyed by a
-//! [`DeliveryKind`] from the URL path, and nothing consumes it until the
-//! swarm→hive channel exists.
-//!
-//! The HMAC code is deliberately **not** shared with `hive-c0re`: that copy is
-//! leaving, and a shared crate is right only when a second consumer arrives.
-//!
-//! **These hooks are registered ALONGSIDE the per-hive ones** — see
-//! [`crate::forge::Client::ensure_swarm_webhooks`].
 
 use anyhow::{Context as _, Result};
 use axum::{
@@ -199,15 +189,11 @@ pub(super) enum DeliveryKind {
 
 /// The route prefix a registered `target_url` must point at.
 ///
-/// ⚠️ Deliberately **not** `/webhook/knowledge` or `/webhook/config-pr`, the
-/// paths the per-hive receivers use. A hive-side registrar deletes any hook
-/// whose URL ends with *its* path but has a different base — see
-/// `hive-c0re`'s `forge::ensure_config_pr_webhook`. A swarm-level hook under
-/// such a path would therefore be deleted by every hive on every boot, and
-/// the symptom is a hook that silently stops existing.
-/// `webhook_urls_survive_the_hive_side_reapers` pins that, and its own doc
-/// records why `/webhook/knowledge` stays in the check even though the
-/// knowledge registrar no longer reaps.
+/// ⚠️ Deliberately **not** `/webhook/knowledge` or `/webhook/config-pr`.
+/// Older `hive-c0re` releases delete, on every boot, any hook whose URL ends
+/// with one of those paths on a base other than their own; a swarm-level
+/// hook there would silently stop existing while such a hive runs.
+/// `webhook_urls_survive_the_hive_side_reapers` pins that.
 const ROUTE_PREFIX: &str = "/webhook/forge/";
 
 impl DeliveryKind {
@@ -661,22 +647,18 @@ mod tests {
         }
     }
 
-    /// A cross-daemon invariant with nothing else to enforce it: a per-hive
-    /// registrar in `hive-c0re` **deletes** hooks whose URL ends with its
-    /// own path but carries a different base. A controller URL matching such
-    /// a suffix would be deleted by every hive on every boot — the swarm hook
-    /// would simply cease to exist, with the cause in a different daemon's
-    /// startup sweep. Serving these under `/webhook/forge/` is what avoids
-    /// it, and this is the only place that says so in a form that fails.
+    /// A cross-daemon invariant with nothing else to enforce it: older
+    /// `hive-c0re` releases **delete** hooks whose URL ends with
+    /// `/webhook/knowledge` or `/webhook/config-pr` but carries a base other
+    /// than their own. A controller URL matching such a suffix would be
+    /// deleted by every such hive on every boot, with the cause in a
+    /// different daemon's startup sweep. Serving these under
+    /// `/webhook/forge/` is what avoids it, and this is the only place that
+    /// says so in a form that fails.
     ///
-    /// `forge::ensure_config_pr_webhook` still reaps that way. The knowledge
-    /// registrar no longer does — it was replaced by a removal that matches
-    /// the full URL, so it cannot touch another hive's hook. **The
-    /// `/webhook/knowledge` arm is kept anyway**, because the hazard is not
-    /// this repository's current code: it is whatever is *deployed*, and a
-    /// hive still running the previous version reaps by suffix until it is
-    /// upgraded. Drop that arm once no such hive can exist, not when the
-    /// source stops mentioning it.
+    /// Current `hive-c0re` removes only hooks matching its own full URL. The
+    /// hazard is what is *deployed*, not this tree: drop this test once no
+    /// hive running an older release can exist.
     #[test]
     fn webhook_urls_survive_the_hive_side_reapers() {
         for suffix in ["/webhook/knowledge", "/webhook/config-pr"] {