scripts: stop collapsing a failed lint scan into a clean pass

check-attribution-trailers.sh used `|| true` on `git log`'s exit status,
so a hard failure (bad range, unborn HEAD) and an empty-but-successful
range were indistinguishable — both fell through to the same
`-z "$commits"` exit-0 path. Capture the status via the `if` guard
(exempt from set -e on purpose) and exit 1 on a real git log failure.

check-issue-refs.sh piped `git ls-files | xargs grep | grep -v
lint:allow`, then swallowed the final exit code with `|| true`. Worse:
xargs itself collapses grep's exit 1 (no match) and exit 2+ (real error,
e.g. an unreadable file) into the same xargs(1) status (123 either way),
so even capturing that status can't tell them apart. Switched to `git
grep`, which runs once over the tracked set and hands back its own exit
status untouched (0 matched / 1 no match / 2+ error) — then branch on
that status explicitly for both the scan and the lint:allow filter step.

Refs #4439, #4442

scripts/check-attribution-trailers.sh

@@ -35,7 +35,16 @@ if ! git rev-parse --verify "$base" >/dev/null 2>&1; then
   fi
 fi
 
-commits="$(git log --reverse --format='%H' "${base}..HEAD" 2>/dev/null || true)"
+# `|| true` here used to erase git log's own exit status, so a genuine
+# failure (bad range, corrupt ref) and a merely-empty range read the same:
+# both fell through to `-z "$commits"` and exited 0 "clean". Capture the
+# status via the `if` guard instead — that's exempt from `set -e` on
+# purpose — so a failure exits loudly and an empty-but-successful range
+# still means "no commits, nothing to check".
+if ! commits="$(git log --reverse --format='%H' "${base}..HEAD")"; then
+  echo "check-attribution-trailers: git log failed for range ${base}..HEAD — see error above" >&2
+  exit 1
+fi
 
 if [ -z "$commits" ]; then
   exit 0