fix(git): let the user's own command be the one that reports

Three from the latest fuzz batch, all in `run_diff`/`run_log`'s handling of
the children RTK runs alongside the user's command.

`git diff` ran its stat probe first and let that probe report failure. The
probe runs with the patch-shape flags stripped, so it answers a different
command than the one that was typed: `git diff -Uabc nonexistent-ref` is
`error: --unified expects a numerical value` (129) to git, and the stripped
probe reported `ambiguous argument` (128) instead. The user's own arguments
now run first and their result is the verdict; the probe is decoration, and
a failure there costs the header rather than the command.

The `[rtk] showing 10 commits` notice announced a truncation that had not
happened -- on a two-commit repo, and ahead of commands git then rejected
outright. When the limit applies the output is bounded by it, so that run is
captured rather than streamed and the notice is printed afterwards, only if
git really produced the full limit, and never when git failed. A non-default
`--format` makes the count unreadable; RTK then says nothing rather than
guessing.

Colour is stripped before the diff compaction parses it. `--color` re-shapes
the very columns the compaction keys on -- the escape sits at column 0, so
`diff --git` and `@@` never match and the body came back empty. RTK renders
its own output, so the colour was never going to survive compaction anyway.
This was reachable on develop for `--color` alone and became reachable for
`--color --unified=0` once `--unified` stopped taking the raw route; the
strip covers both, plus the `color.ui = always` config form that no argument
inspection could have caught (rtk-ai/rtk#3842).

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