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

nix/host-modules/hive-gateway/vhosts.nix

@@ -135,9 +135,7 @@ let
 
   # Shared auth block — separate locations don't inherit auth_basic, so
   # each dashboard location (`/`, `/api/`) needs it or that surface is
-  # unauthed. `/webhook/` is intentionally excluded: Forgejo cannot
-  # send HTTP Basic credentials with webhook deliveries, and the HMAC
-  # secret (`X-Hub-Signature-256`) protects those endpoints instead.
+  # unauthed.
   dashboardAuth = lib.optionalString cfg.auth.enable ''
     auth_basic "${cfg.auth.realm}";
     auth_basic_user_file /var/lib/hive-gateway/conf/gateway.htpasswd;
@@ -147,15 +145,14 @@ let
   '';
 
   # Dashboard: nginx static-serves the dist, c0re is API-only. Routing
-  # is by PATH, never content-type. c0re serves exactly three prefixes —
-  # `/api/` (all dashboard data + actions + the SSE streams), `/webhook/`
-  # (knowledge push + config-PR approval triggers, HMAC-guarded), and
+  # is by PATH, never content-type. c0re serves exactly two prefixes —
+  # `/api/` (all dashboard data + actions + the SSE streams) and
   # `/health/` (liveness + readiness) — so those proxy to c0re and
   # everything else serves the dist with an SPA fallback to index.html.
   # Path routing is deterministic where an Accept-header split would make
   # the SAME url behave differently by content-type (e.g. `/api/state`
   # fetched with `Accept: text/html` wrongly getting index.html). A new
-  # top-level c0re route prefix (beyond /api + /webhook + /health) needs
+  # top-level c0re route prefix (beyond /api + /health) needs
   # a matching location added here.
   dashboardProxyLocation = {
     "/" = {
@@ -176,15 +173,8 @@ let
         ${dashboardAuth}
       '';
     };
-    "/webhook/" = {
-      # No dashboardAuth here: Forgejo cannot send HTTP Basic credentials
-      # with webhook deliveries. HMAC (X-Hub-Signature-256) is the auth
-      # for these endpoints; hive-c0re verifies it in the handler.
-      proxyPass = "http://${cfg.upstreamHost}:${toString cfg.upstreamPort}";
-    };
     "/health/" = {
-      # No dashboardAuth here either, for a different reason than
-      # /webhook/: an external uptime monitor generally can't do
+      # No dashboardAuth here: an external uptime monitor generally can't do
       # interactive HTTP Basic. The endpoints themselves are scoped to
       # status + warning kind/message (see hive-c0re/src/dashboard/
       # health.rs) — no tokens, no agent detail — so exposing them