fix(run): --files takes several paths, as upstream does

[blairham]

Found while doing the launch-readiness pass for #43.

The bug

$ pre-commit run trailing-whitespace --files a.txt b.txt
Error: expected at most 1 argument, got 2

Nothing runs, and no file is touched. Upstream, measured on the same repo with the same config:

$ pre-commit run trailing-whitespace --files a.txt b.txt
trim trailing whitespace.................................................Failed
- hook id: trailing-whitespace
- exit code: 1

Fixing a.txt
Fixing b.txt

	upstream 4.6.2	this tool, before
exit code	1	1
a.txt fixed	yes	no
b.txt fixed	yes	no

Why

Upstream declares --files with argparse's nargs='*', so one flag swallows every following path. go-flags has no equivalent — a []string field means repeat the flag, binding exactly one value per occurrence. The second path fell through as a stray positional, hit the at-most-one-hook-id check, and the run died before any hook ran.

This is not an exotic invocation. --files with several paths is the ordinary way to scope a run — diff-scoped CI, xargs, editor integrations — and it was broken in both commands that accept the flag, run and try-repo.

The fix

One helper, called by both commands rather than copied into try_repo.go, rewriting the greedy form into the repeated form before go-flags sees it. Each semantic was confirmed against a real 4.6.2 argparse parser rather than assumed:

invocation	files	positional
--files a b c	[a b c]	—
--files a b hook	[a b hook]	— (greedy really does swallow it)
--files=a b	[a]	b
--files a --other	[a]	—
--files a -- b	[a]	b
--files	[]	—

Help text said --files=FILE, which described the broken behavior accurately. It now reads --files [FILES ...], like upstream's.

Why 78/78 did not catch it

Nothing in the differential suite ran a multi-path invocation. There is now a check that runs both binaries with two paths and compares exit code, output, and the files on disk.

Comparing exit codes alone would not have caught it either — upstream exits 1 because the hook failed, this exited 1 because it could not parse, and "both non-zero" matches. The discriminating assertion is the filesystem one: both files fixed, or the bug is back.

Verified by mutation — reverting the one-line wiring in run.go turns three of the four new checks red:

[PASS] [exit code ] --files with several paths exits alike (py=1 go=1)   <- non-discriminating
[FAIL] [output    ] --files with several paths does not fail to parse
[FAIL] [filesystem] --files fixed a.txt
[FAIL] [filesystem] --files fixed b.txt

Verification

make check and make lint clean; parity suite green against upstream 4.6.2 with PARITY_REQUIRE=1.

Separately: that mutation run also showed the parity suite exits 0 with failing parity checks — nothing calls t.Error on a mismatch, so the job that ci.yml describes as failing "before review rather than after a merge to main" cannot currently fail. That is a distinct problem and gets its own PR.

Refs #43