A renamed verb walks past the shim in silence

[HackingGate]

A match list names verbs literally, and every command the shim stands in front
of lets a person rename one. The renamed verb matches nothing, so the shim execs
a publishing command unexamined, prints nothing, and exits 0.

Repro

With the binary installed as a PATH shim and a policy declaring the shipped
git table (match = ["push:*"], collect = "git-refs"):

git -c alias.p=push p origin HEAD:refs/heads/private-name
# exit 0, no stderr, the push happens, no checker ran

The persisted form is the same:

git config alias.p push
git p origin fix/acme-outage    # exit 0, nothing checked

gh alias set and glab alias set give the same result against the gh and
glab tables.

Cause

Shim::names (src/shim.rs:494) matches verb:noun against the match list as
literal text, and Shim::reading (src/shim.rs:499) has three answers: Named,
Absent, Unclear. An alias lands in Absent, which is the answer that means
"the policy was read and this command line is not one it stands in front of".
Nothing anywhere asks the command what the word expands to.

Fix

Where nothing matches, and only there, resolve the first positional word once
and match again against the expansion:

• git: git config --get alias.<word>, honouring any -c alias.*=<value>
  written on the command line, which outranks the config file and costs no
  process to read.
• gh and glab: <command> alias list.

The expansion has to be asked of the REAL command rather than of whatever PATH
resolves, since PATH resolves to the shim.

A shell alias (!...) and a lookup that failed are could-not-looks and not
absences: exit 2 with a message. What a shell runs is not an invocation any
table can read, and it may well be a push.