docs(security): correct the operator-merge bullet (mara review)

Per mara: branch protection isn't a blanket enforced check, and it's not
set up for external VCS (GitHub). Reframe the bullet as the operator-merge
*convention* — technically enforced only on the core-managed config repos,
and explicitly NOT wired up for GitHub/external VCS (process + accepted
risk there, not a control).

docs/security.md

@@ -52,11 +52,13 @@ shell) on the attacker's behalf.
 Mitigations are therefore about **bounding capability and inserting human
 checkpoints**, not about sandboxing the agent from its own tools:
 
-- **Branch protection** — agents may *push* branches, but PRs are **merged by
-  the operator only** (existing hive convention; enforced on `main` via
-  branch-protection rules). This puts a human in the loop on the highest-value
-  action. It applies to **any** external VCS access too (GitHub etc.), not
-  just the internal forge.
+- **Operator-merge convention** — an agent may *push* branches, but the norm
+  is that **a human (the operator) merges the PR**, keeping a person in the
+  loop on the highest-value action. This is largely **convention, not a
+  blanket enforced gate**: the internal forge applies branch protection only on
+  the `core`-managed config repos (the config-PR merge flow), and it is **not**
+  set up for external VCS (GitHub etc.) — there, operator-merge is process and
+  accepted risk, not a technical control.
 - **Approvals** — config changes, schedule additions, and other
   blast-radius-y operations route through the operator approval queue
   (see [`approvals.md`](approvals.md)).