docs: config changes are operator merges on the forge

Rewrites the config-change flow around the forge merge and the
DeployRequest{rev} deploy, drops the MergeConfigPr approval, its deploy
DAG, the hive's `/webhook/` route and the `core` merge allowlist from
the docs, and states that operators join the `operators` team by hand.

Refs #4850

docs/trust-boundary/security.md

@@ -123,14 +123,17 @@ checkpoints**, not about sandboxing the agent from its own tools:
   highest-value action. On the **internal forge this is technically enforced,
   not just convention**: agents can't create repos (`max_repo_creation = 0`),
   and `main` on an `agent-configs/<name>` repo carries swarm-controller's
-  branch protection: merge allowlisted to the `operators` team, with one
-  approval from it. Existing `agents/<repo>` repos carry the same merge gate.
+  branch protection: merge and approval allowlisted to the `operators` team,
+  which swarm-controller converges on every config repo. An operator's merge
+  there is also what deploys the config. Existing `agents/<repo>` repos carry
+  the same merge gate.
   An agent (a write collaborator, not a repo admin) can neither change those
   settings nor merge its own PR. It's **not** set up for external VCS (GitHub
   etc.), though — there, operator-merge is process + accepted risk, not a
   technical control.
-- **Approvals** — config changes, schedule additions, and other
-  blast-radius-y operations route through the operator approval queue
+- **Approvals** — schedule additions and other blast-radius-y operations
+  route through the operator approval queue; config changes are config PRs
+  an operator merges on the forge
   (see [`approvals.md`](../agent-lifecycle/approvals.md)).
 
 ### Capability = accepted risk