fix(merge): wire pr_already_merged guard into deployer merge path (idempotent re-merge)

The pr_already_merged guard was defined + unit-tested but consulted by zero
production code, while ADR-001 Р-3 / README / CHANGELOG claimed the merge path
consults it before a repeat merge (reviewer P1, ORCH-065 attempt 2/3). The
actual merge actor is the LLM deployer agent (it merges the feature PR at the
start of the `deploy` stage), so on a reaper re-drive of an already-merged PR
the deployer would blindly re-merge → Gitea error → false БАГ-8 rollback; AC-11
("no second merge") was not met deterministically.

Wire the guard at the real consultation point — the deployer prompt — so it
runs merge_gate.pr_already_merged before any (re-)merge and no-ops when the PR
is already merged. check_branch_mergeable is left untouched (AC-13: check_*
behaviour unchanged; it runs on the first deploy-staging→deploy edge, not on a
deploy-stage re-drive where the second-merge risk lives).

- .openclaw/agents/deployer.md: idempotent pre-merge guard step + general rule.
- src/merge_gate.py: docstring names the deployer-prompt consultation point.
- docs/architecture/README.md, CHANGELOG.md: state the consultation point so
  golden-source matches implementation.
- tests/test_merge_gate.py: regression test asserting the deployer prompt wires
  the guard (so it can't silently become dead code again).

pytest tests/ -q: 743 passed.

Refs: ORCH-065
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

src/merge_gate.py

@@ -453,6 +453,15 @@ def pr_already_merged(repo: str, branch: str) -> bool:
     merge-related helper and it does NOT merge — it only READS the PR state via
     the existing Gitea client, so it does not introduce duplicate merge logic.
 
+    Consultation point: the actual merge actor is the **deployer agent** (it merges
+    the feature PR at the start of the ``deploy`` stage — see webhooks/gitea.py),
+    so the wiring lives in the deployer prompt (``.openclaw/agents/deployer.md``),
+    which runs this exact function before any (re-)merge. The merge-gate quality
+    check (``qg.checks.check_branch_mergeable``) is intentionally NOT modified
+    (ORCH-065 AC-13: ``check_*`` behaviour unchanged) — it runs on the FIRST
+    deploy-staging -> deploy edge and does not re-run on a ``deploy``-stage re-drive,
+    which is exactly where the second-merge risk lives.
+
     Queries Gitea ``GET /repos/{owner}/{repo}/pulls?state=all&head=<branch>`` and
     reports True when any matching PR has ``merged == True``. Never raises (AC-9):
     any HTTP/parse error -> ``False`` (conservative: "not known-merged" lets the