Close Three Small GH_REPO and Merge-Message Gaps in the Write Guard #3145

Context

Found by the final local review of #3135, which reads GH_REPO as a gh write's target and extends the --admin run-time scan. The first two items are on text that pull request wrote, and the third is in a helper develop already has, which the new GH_REPO reading now reaches too. Each was confirmed with classify probes on constructed commands, origin example/repo.

Three Small Gaps

• The merge deny message lists the allowed run-time shapes incompletely. It allows a quoted value of an option other than --repo, and a quoted word where gh's command or subcommand goes. A quoted run-time word where gh itself goes is allowed too, as "$G" pr merge 5 --squash is, and the message leaves it out.
• gh api's older :owner and :repo placeholders are not read. The GH_REPO reading takes a value on gh api only where a word holds {owner} or {repo}. So GH_REPO=stranger/example gh api -X POST repos/:owner/:repo/issues/1/comments -f body=x is allowed, if gh still fills the older spelling.
• A [HOST/]OWNER/REPO value is split at its first slash. _named_target reads github.com/example/repo as owner github.com, so GH_REPO=github.com/example/repo gh pr comment 5 -b x is denied, though it writes to the origin. Develop denies --repo github.com/example/repo the same way.

Possible Direction

Name the quoted command word in the message's exception list. Confirm with a read-only gh api repos/:owner/:repo call whether gh still fills :owner, and read it where it does. Read a three-part value's owner as its middle part.