Add a GitHub-native human review and authorization flow

[pengfei-threemoonslab]

Parent epic: #338

Depends on #333 and consumes the completed permission/current-control work in #335 and #339. This issue is GitHub PR-time authorization only. #293 remains the separate, blocked in-session host-attestation problem.

Problem

When verification requires human judgment, the user needs a concrete review question, an authenticated review surface, and an exact continuation. Conversation acknowledgement intentionally cannot change control state, but the current product does not provide an equally obvious GitHub-native route that binds the decision to the reviewed bytes.

Proposed direction

Publish a GitHub PR check/review surface that binds:

• repository and verification request ID;
• head commit/tree and reviewed change;
• policy snapshot and decision identity;
• authenticated reviewer identity and decision;
• the exact verifier continuation after review.

The coding agent may publish evidence when #335 permits it, but it must not be able to create, forge, or reuse the human authorization.

Acceptance criteria

• Every GitHub human-review route names the precise question the reviewer must decide.
• The review/check binds repository, request ID, head/tree, reviewed change, policy snapshot, and reviewer identity.
• Token/permission isolation proves the coding agent cannot approve its own change.
• Stale approval cannot authorize a later commit, diff, request, or policy snapshot.
• The exact environment-valid verifier continuation is published after review.
• PR checks/comments distinguish “publishable for review” from “merge authorized.”
• Report, verifier, receipt, and packet reproducibility remain deterministic; authenticated review is a separately bound input, not an invisible mutation.
• The implementation does not claim to solve Host-authenticated in-session approval receipts (unblock user-approved high-risk host-grant edits) #293 unless a host-attestation design independently clears that issue’s prerequisites.

Product principle

Humans should enter the loop to make a semantic or authority decision—not to debug Git topology, Python environments, or artifact routing.

[pengfei-threemoonslab]

This may unblock #293.

#293 (host-authenticated in-session approval receipts) has been sitting blocked on one prerequisite: "a host integration willing to attest." Without a host that can vouch that a specific human answered a specific prompt, the design yields annotation-only receipts and cannot clear a human route.

This issue proposes GitHub as exactly that host — "a GitHub PR review/check that binds approval to repository, request ID, head SHA, policy snapshot, and reviewed change." GitHub can attest identity in a way a local IDE hook cannot: the review is authenticated, server-side, and not writable by the agent's tool surface.

If that reading holds, #293's prerequisite is satisfiable and its blocked label should come off once this lands. Worth confirming deliberately rather than by accident, because #293 also records three disqualifiers that any approval design must clear, and they apply here:

1. Agent-forgeable. A receipt an agent can write is self-approval with extra steps. A GitHub review is not agent-writable provided the agent's token cannot approve — which is not automatic, since a bot token often can.
2. Wrong tense at preflight. Receipts bind landed bytes; preflight routes proposed edits. A PR review binds a head SHA, so this is the right tense for PR-time but not for local pre-edit routing.
3. Cannot reach CI, must not reach reports. A GitHub review can reach CI, which is the improvement over the rejected local-ledger design. But the acceptance criterion from Host-authenticated in-session approval receipts (unblock user-approved high-risk host-grant edits) #293 still applies: report.json and packet artifacts must stay byte-identical with and without an approval, or the same commit produces different artifacts on different machines.

Also note this bears on #313 — the open decision about whether the weak-evidence residual routes to #293. If GitHub becomes a viable attesting host, that decision gets easier and should be revisited after this lands rather than before.

Scope note. The acceptance criterion "repeated findings with one root cause are aggregated with affected_paths[]" is really #336's normalization problem surfacing in the review UI. Worth keeping the aggregation in the finding layer rather than implementing a second aggregation in the review surface.