diff --cached --no-ext-diff --find-copies-harder --quiet exits with wrong status code

["D. Ben Knoble" <ben.knoble@gmail.com>]

AFAICT, you need all of the mentioned options to trigger the bug.
Allowing ext-diff works fine, I don't think it's triggered in
non-cached diffs, and I've never seen it without --find-copies-harder.
Notably, s/quiet/exit-code works just fine.

Here's a repro from git.git:

    cp git{,1}.c
    git add git1.c
    git diff --cached --no-ext-diff --quiet --find-copies-harder &&
echo 'this should exit 1!'

(And of course, ^quiet^exit-code if your shell supports it yields a
different outcome)

Context: my distro applies a patch that allows
diff.renames=copies-harder. In a repo with that turned on,
git-prompt.sh stopped showing some staged changes.  Turns out it runs
git diff with all these flags (less --find-copies-harder, which is
enabled by the config option). I _have_ confirmed this bug exists in
unpatched Git, however.

Some rough debugging notes: when entering diffcore_std (or
diffcore_rename_extended's cleanup loop):
- for exit-code, diff_queued_diff.nr matches "git ls-files :/ | wc -l"
- for quiet, it's just 1 (the first file listed by git ls-files :/, AFAICT)
The only other obvious difference I spotted is that the "quick" flag
is turned on for quiet, which makes sense.

I tried to figure out who builds the queue, and it looks like it's
diff_cache -> unpack_trees -> ..., where at some point for exit-code
we _keep_ queuing files, but for quiet we don't.

I also saw diff_cache tweaks opts.diff_index_cached based on
--find-copies-harder, but I haven't looked further to see how that
affects things or what the interaction with ext-diff is.

Help welcome, thanks.

-- 
D. Ben Knoble