The merge gates and confirmation chain run in Go before the write #870

Problem

After the preconditions pass, squash-merge.sh activates the unattended policy gates, which run on any merge without an explicit --confirmed, even outside unattended mode, and neither a session pre-approval nor a delegation bypasses them. It then asks for confirmation, from --confirmed, a session pre-approval or the delegation checker, and reads the live state and the stamp again, because the confirmation is another program that may have changed them. It is under the shell freeze in #588, and no later step can walk a merge back.

Part of #324, within #588. Child 25 in #324's Children list. Replaces the gate activation, confirmation and re-read part of packages/agents/source/skills/merge-pr/shared/scripts/squash-merge.sh.

Acceptance criteria

1. AC1: Given no --confirmed, when the command runs, then the unattended policy gates of child 05 run before the confirmation chain, in attended and unattended mode alike, and a session pre-approval or delegation answer does not bypass a gate refusal; given --confirmed in attended mode, then the unattended policy gates are not run (the initial required-review and check-rollup preconditions of child 10 still apply).
2. AC2: Given a confirmation from --confirmed, then a session pre-approval for merge, then the machine delegation check, in that order, when the gates have passed, then the first to answer wins and the output names it; given a refusal it exits 1, and given no answer it exits 75 and merges nothing.
3. AC3: Given the delegation check runs, then it receives check <repository> merge --pr <number> --head <sha>, plus --owner-path when the gates ran and owner paths appear in the policy.
4. AC4: Given the confirmation step changed the draft, stamp, head, base or base commit, when the live state is read again, then the command refuses before any write.
5. AC5: Given the gates are active, when the live state is read again after confirmation, then the gates run again on it and the command refuses when the re-read approvals or checks fail the applicable gates, and proceeds when they still satisfy them (an additional valid approval or another passing check does not refuse); given an explicit --confirmed the approval and check gates are not re-run.
6. AC6: Given a stamp that records unattended repository configuration or a trusted policy authority, when the command validates it, then it applies the bindings of refactor(agents): port review snapshots and stamps to Go #769 and refactor(agents): port trusted review policy and prompt assembly to Go #763 as established there, including their intentional corrections, and refuses on a mismatch; given an unrelated trusted-ref commit with the policy unchanged, then the stamp is accepted.
7. AC7: Given a confirmation answered through refactor(agents): port confirmation and delegation resolution to Go #762, when the command runs, then it consumes that contract for the answer and refusal text without a private copy.
8. AC8: Non-functional: authority comes from the confirmation chain and machine configuration only, and the command runs against fakes on macOS, Linux and Windows in CI.
9. AC9: Given the final check before the write, when it runs, then it repeats the integrity check against the pinned base through Run the skill-directory integrity gate in the merge entry points #982's agentrepo merge integrity, uses the trusted snapshot for helpers and removes it on every exit path.

Scope and non-goals

Scope: gate activation, the confirmation chain and the post-confirmation re-read in agentrepo merge run, ported from confirmation.bats and delegation.bats cases.

Non-goal: the preconditions (child 10), the merge write (child 11) and cleanup (child 12). Non-goal: the confirmation library, which #762 owns. Non-goal: editing the shell script before child 14.

Approach

Meet AC1 to AC9 with failing cases first: run the shell script and the Go command on the same fakes and compare status, streams and the checker arguments. Mechanism is the implementer's choice.

Dependencies

Blocked by: #864, #869, #333, #762, #763, #769, #982.

Prerequisites: #762 (confirmation chain), #769, #763, #321, #333 and #982 (integrity command and snapshot).

Size

S. One pull request.

Verify plan

• AC1, AC2: a table over the three answerers and their refusals with and without --confirmed, following the cases from tests/skills/agent-merge-pr/confirmation.bats.
• AC3: a recording delegation checker asserting its arguments with and without owner paths.
• AC4, AC5: a confirmer fake that changes state, including an invalidating approval or check change (refused) and a still-qualifying one (proceeds), and a gate-active versus --confirmed matrix.
• AC6: stamp cases with and without recorded configuration, one mismatch each, and integration cases for the refactor(agents): port trusted review policy and prompt assembly to Go #763 policy digest, status and authority bindings including an unrelated trusted-ref commit with unchanged policy (accepted).
• AC7: a test that the answer and refusal text come from the refactor(agents): port confirmation and delegation resolution to Go #762 contract.
• AC8: authority keys supplied from the repository file and ignored; the CI matrix run.
• AC9: tests where a skill directory differs from the base lock at the final check, asserting the refusal comes before any write, helpers run only from the snapshot (a sentinel-writing checkout helper never runs), and the snapshot directory is gone after a pass, a refusal and a failure.
• Definition of done: D1 each AC is verified at the merged head, with the commands and results cited in the pull request's Verification. D2 an independent review approves the exact merged head, and every finding has a recorded disposition. D3 required checks pass with no gate loosened. D4 the leak scans the repository specifies are clean, and every post made for this work passes the per-post leak review before it is posted. D5 every commit is signed. D6 the documentation matches the change or the Verification says why there is no impact. D7 every commit has an Assisted-by trailer and the pull request has the provenance:agent-assisted label. D8 the pull request stays within the size limits. D9 follow-ups are filed as issues and listed under Related. D10 the merge closes the issue through a closing reference, the board shows Done, and the final Status: comment names the merge commit.

Risks

A gate bypassed by a confirmation, or a state change after confirmation going unnoticed, would merge something nobody reviewed. AC1 and AC4 hold both. Undo: revert; the shell script is untouched.

Operator authority

None. The Go files are new, and nothing in this area edits an owner-tier path: deleting merge-agent.sh and merge-policy.py is the single cutover under #588.