docs(pm-agent): correct the handoff — a STALE approval still satisfies the gate

I recorded that merging main in would dismiss the operator's approval and that
approval-policy would therefore go red until they re-approved. Measured: wrong.

dismiss_stale_approvals is true, so the review did go stale — but
ci/approval-policy.sh selects on .state == "APPROVED" and a non-author login and reads
nothing about staleness, and required_approvals is 0 so Gitea never required one either.
CI run #257 on the merged head: "approved by 'jakman85' (author 'gitea-admin') —
sensitive change is human-reviewed", approval-policy pass, gitea-settings pass, required
check green, PR mergeable.

The 'push again and you must override again' rule applies to the /approve-override
directive, which IS staleness-checked against the head commit — not to a review.

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>

decisions/2026-10-05-pm-agent-issue-to-pr.md

@@ -190,14 +190,31 @@ measured example.** Two consequences were handled rather than noted:
   not look, and have its work committed by nobody while the issue got a "changed nothing"
   report. The rules file now tells it §0 is already satisfied and not to make a worktree.
 
-**The operator's approving review on PR #57 is dismissed by this push.** Measured on the
-live branch protection: `dismiss_stale_approvals = true`, `ignore_stale_approvals = false`.
-A conflict cannot be resolved without a new head, so this is unavoidable rather than a
-choice — but it means `ci/approval-policy.sh` goes red again (`required_approvals` is 0, so
-Gitea itself does not block; the gate stage is what demands the non-author review) and the
-operator has to re-approve, or post `/approve-override <reason>` as a PR **review**. That is
-theirs to do; an agent posting it on its own PR is the self-approval the stage exists to
-prevent.
+**The operator's approving review goes STALE on each new head, and the gate does not care.**
+I first wrote here that it would need re-approving. That was wrong, and the correction is
+worth keeping because it is a fact about this repository's gate rather than about this
+change:
+
+- Measured on the live branch protection: `dismiss_stale_approvals = true`,
+  `ignore_stale_approvals = false` — so pushing the merge did stale `jakman85`'s review
+  (confirmed: `GET /pulls/57/reviews` → `APPROVED`, `stale: true`).
+- But `ci/approval-policy.sh` selects reviews on `.state == "APPROVED"` and
+  `.user.login != author` and reads **nothing about staleness** (line 147). So a stale
+  approval still satisfies the sensitive-path rule.
+- And `required_approvals = 0`, so Gitea's own merge button never required one either.
+
+Measured, not inferred: CI run **#257** on the merged head printed
+`approved by 'jakman85' (author 'gitea-admin') — sensitive change is human-reviewed.` →
+`stage approval-policy: pass`, with `gitea-settings: pass` as well. The job's own exit was
+`MERGE GATE: UNDETERMINED` (rc 3 — `spec-immutability` and `conformance` skipped, as the
+workflow tolerates with `|| [ $? -eq 3 ]`), so the required check
+`gate / gate (pull_request)` is **green** and PR #57 reports `mergeable: true`.
+
+Nothing is therefore waiting on the operator except **the merge itself**, which is theirs
+by CLAUDE.md §1 and never an agent's. Worth noting for whoever reads this later: the rule
+"push again and you must override again" applies to the `/approve-override` **directive**,
+which is staleness-checked against the head commit — not to an ordinary approving review,
+which this gate accepts stale.
 
 ## What I did NOT verify