Read a Repo Flag Placed Before the gh Subcommand in the Write Guard's Target Check #3093

Context

Found from Copilot's review of the develop -> main promotion pull request #3092, whose headline said the guard can misidentify pr merge when pr is a global-option value. Confirmed with classify probes on constructed commands against both main's and develop's guard, so this is pre-existing rather than something the promotion introduced.

A Repo Flag Before the gh Subcommand Hides the Target

gh accepts a command's -R/--repo before the subcommand, as in gh -R example/repo pr view 5, since cobra skips flags when it finds the subcommand and the flag is then parsed by the command it found. The guard reads a gh write's target only after the subcommand, so a repo flag placed before it is never read:

• gh -R stranger/example pr merge 5 --squash is allowed under an origin of example/repo.
• gh --repo=stranger/example pr merge 5 --squash and gh -Rstranger/example pr merge 5 --squash are allowed the same way.
• gh -R stranger/example issue comment 5 --body hi and gh -R stranger/example pr create --title t --body b are allowed too.

gh pr merge 5 --squash -R stranger/example is denied, so only the position hides the target.

The literal case the review named, a -R whose value is pr, does not run: gh refuses it with expected the "[HOST/]OWNER/REPO" format, got "pr". The same position does make _runs_gh_pr_merge, which takes the first pr word as the subcommand, mislocate the subcommand, so the reading below fixes both.

Possible Direction

Find the subcommand the way cobra does, past any flags and their values before it, and read a repo flag wherever it sits in the argv, before or after the subcommand. This is the same class as #3080, a flag between pr and the write subcommand, and one reading can close both.