fix(git): stop the log limit and the body suppressor overreaching

Two consequences of earlier fixes on this branch, both caught by fuzzing
`log` and `show` against raw git.

The raw-shape `git log` passthrough capped every walk at 10, including one
the user had already bounded: `git log -p HEAD~15..HEAD` came back with 10
of the 15 commits it named. The cap exists because that route streams
straight to the terminal and an unbounded patch request printed the entire
history, so it stays -- but a revision range is an exact bound the user
chose, and it is now left alone. When the cap does apply it says so on
stderr, since there is no footer or tee on that path to notice the missing
commits from.

`run_show` read `-s`/`--no-patch`/`--quiet` as an order-independent "any",
where git resolves them against `-p`/`--patch`/`-U<n>` by last flag wins:
`git show -s -p` prints the diff and `git show -p -s` does not (git 2.53).
A patch requested last was therefore swallowed, and never_worse kept the
smaller summary, so it vanished without trace. `emits_word_diff` in the
same file already modelled this correctly.

`git show --oneline` no longer prints its summary line twice. The stat step
passes `--pretty=format:` to suppress the commit header, and the user's
`--oneline` outranked it by the same last-wins rule, so that step reprinted
the header the summary step had already produced. The step drops `--oneline`
from what it forwards rather than appending its own flag afterwards: past a
user `--` that flag would be a pathspec, which is the failure this branch
exists to prevent -- and an integration test caught the first attempt doing
exactly that.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>