Read an Inherited GH_REPO From the Session Environment in the Write Guard #3147

Context

Raised by Copilot on the develop -> main promotion #3146, against the GH_REPO reading #3135 added. The gap is older than that reading: main's guard reads no GH_REPO at all, so it allows the same commands. Confirmed with classify probes on constructed commands, origin example/repo, run under both guards with GH_REPO=stranger/example set in the hook process's own environment:

main=allow dev=allow | gh pr comment 5 --body hi
main=allow dev=allow | gh issue create --title t --body b
main=allow dev=deny  | GH_REPO=stranger/example gh pr comment 5 --body hi

Gap

_gh_repo_assignments reads GH_REPO only from the command text, from a prefix or an earlier export. A session whose own environment already holds GH_REPO passes it to every gh call the Bash tool runs, so gh pr comment 5 --body hi writes to the repository that value names while the guard reads no target and compares the checkout's origin instead.

Possible Direction

Read GH_REPO from the hook's environment, through the environ seam classify already takes, as the value reaching a gh word where the command text sets none and no repo flag names one. A command-text assignment or a repo flag still overrides it, as gh reads it. Confirm first that the hook process inherits the environment the Bash tool's commands run in.