-- is honoured by some commands and treated as a filename or an invalid option by others

[davydog187]

-- is honoured by some commands and treated as a filename or an invalid option by others.

POSIX: -- ends option parsing; everything after it is an operand. Every command below is given the same
argument list, and they disagree three ways.

command	just_bash	GNU / BSD
shasum -- /f	rc=1, shasum: --: No such file or directory — and the correct hash on stdout	rc=0
sha256sum -- /f	rc=1, same shape	rc=0
cat -- /f	rc=1, cat: --: No such file or directory	rc=0
md5sum -- /f	rc=1, invalid option '--'	rc=0
base64 -- /f	rc=1, invalid option '--'	rc=0
sort -- /f	rc=0	rc=0
wc -l -- /f	rc=0	rc=0
head -- /f	rc=0	rc=0
tac -- /f	rc=0	rc=0
rev -- /f	rc=0	rc=0

Three distinct wrong behaviours: -- resolved as a path (shasum, sha256sum, cat), -- rejected as
an option (md5sum, base64), and -- handled correctly (sort, wc, head, and tac/rev as of
PR #74).

shasum -- /f is the worst of them: it exits 1 with a diagnostic while also printing the correct
hash, so a caller checking the exit code and a caller reading stdout disagree about whether it worked.

-- is the standard way to pass a filename beginning with a dash, so this is reachable from ordinary
input rather than only from adversarial input — and it interacts with the strict unknown-flag work in
#68, since that is what makes a leading dash an error rather than a filename.

The table above is not exhaustive; it is what one verification pass happened to touch. This wants the
same treatment as #68's unknown-flag matrix — enumerate cmd -- FILE for every command in
Commands.Registry that takes a file operand, assert rc=0 and correct output, and keep it enumerated so
new commands are forced to classify.

---

Pre-existing — identical at d59d84d. PR #74 fixed it for tac and rev only; that commit message
asserts "-- ends the options", which is now true in two more commands than before and still false in
five.

Found by an independent verification pass while working #70.