Post an mh/gauntlet commit status after the merge-time gauntlet, so branch protection can require it #742

Follow-up to #735 / PR #740 (operator-approved plan, 2026-10-28).

Why

After #740, a push runs lint only; the full gauntlet runs in merge-pr.sh / sync-pr-head.sh. A merge made any other way (GitHub web Merge button, a bare gh pr merge, an MCP merge without --verify) reaches develop with no gauntlet at all. Before #740 every branch had at least passed the gauntlet at push. There is no CI and branch protection requires no status checks.

Design

1. After gauntlet_full passes on a sha (or a cached pass for its tree is found), merge-pr.sh and sync-pr-head.sh post a commit status on that exact sha: context mh/gauntlet, state success, a description naming the tree hash. merge-pr.sh --verify posts it too once its cached-pass check passes (cloud: through whatever API path the cloud session has; if none, say so and keep --verify as the gate).
2. A red gauntlet posts nothing (or failure), never success.
3. Operator step, not in the PR: branch protection on develop requires status mh/gauntlet and "Require branches to be up to date before merging". With both, GitHub refuses any merge whose head lacks a pass, through every path, and the head equals the merged tree (closes the develop-moved race between the last fetch and gh pr merge).
4. Docs: branching-model.md (merge paths, the protection settings), repo-gotchas.md, env-vars.md if a knob is added.

Done when

• A test shows merge-pr.sh posts mh/gauntlet: success on $head only after a green or cached gauntlet, and never after a red one (stub the API call).
• The PR body lists the exact branch-protection settings for the operator to apply.

Open

• Who can post a status: any token with repo scope can, so the status is an honest-agent gate, not a security boundary.