fix(standards): say why the base-SHA fetch failed, not just that it did

[twistedmelonman]

The fallback warning discarded git's stderr (2>/dev/null), so a run that fell back to a whole-repo sweep reported that it happened and never why. That turns a diagnosable fault into a rate you can only sample.

-          if git -C repo fetch --depth=1 origin "${BASE_SHA}" 2>/dev/null; then
+          if fetch_err=$(git -C repo fetch --depth=1 origin "${BASE_SHA}" 2>&1); then

...and the else branch appends git said: ${fetch_err}, collapsed to one line so the annotation stays readable.

Why this is safe under set -euo pipefail

fetch_err=$(...) used as an if condition is exempt from -e, so a failed fetch takes the else branch rather than aborting the step.

Validated against a known-bad case rather than assumed — an unreachable SHA with no origin configured:

::warning::could not fetch base deadbeef...; falling back to whole-repo sweep — git said: fatal: 'origin' does not appear to be a git repository fatal: Could not read from remote repository. ...
reached end, exit code preserved
script rc=0

Context

Found while re-measuring the fallback rate, which turned out to be zero rather than the previously reported ~27% (see smartwatermelon/dev-env#121). This is the one real gap that survived that correction. It is a diagnostics fix, not a W3 blocker.

Note on rollout

This does not reach any caller until @standards-check-v1 is moved to the merge commit — a deliberate manual step, not part of this PR.

Checks

yamllint clean · zizmor no findings · code-reviewer PASS · adversarial-reviewer PASS

https://claude.ai/code/session_01ESsw699T54JHARkQXrdL3o