main went red on the push run for #542 with four failures in
TestJsonFormat, all reading 'skip' where they assert 'pass'. Nothing
regressed: the tests had been measuring the repository they run in.

Each of the four supplies a message, on stdin or in a file, which makes
it a prospective commit -- so _resolve_current_author reads
`git config user.name` and falls back to HEAD's author. Both are
ambient. A GitHub runner configures no git identity (no workflow here
sets one), so the fallback always decides, and #542 was a dependabot
merge: HEAD's author was dependabot[bot], which cchk.toml lists in
[commit] ignore_authors. Every commit check skipped, and overall status
is 'skip' when they all do.

Reproduced against a clone pinned to 9f12a63 with the global and system
git config disabled, which is what the runner looks like:

    HEAD author : dependabot[bot]
    user.name   : ''        -> status 'skip'   (the four failures)
    user.name   : set       -> status 'pass'   (why laptops and PRs were green)

So it was never about #542's contents, and it will recur on the next
bot-authored merge to main.

The four now take a `pinned_author` fixture that fixes both identity
sources, leaving the verdict to come from the message under test. The
two tests in the class that already passed are the two that happened to
patch get_commit_info for other reasons -- the same pin, arrived at by
accident.

Pinning it in a fixture would hide the fallback everywhere it applies,
so it is now asserted directly instead: a new test drives an
unconfigured identity with a bot as HEAD's author and expects every
check to skip, exit code still 0. What silently decided other tests'
results is now a contract of its own.

Verified in that clone: 4 failed before, 7 passed after, and the full
suite is unchanged in both a configured and an unconfigured environment.


Claude-Session: https://claude.ai/code/session_01U9zFxq8V4qxG4aMzJhGBFn

Co-authored-by: Claude Opus 5 <noreply@anthropic.com>

Removed extra line break before 'Quick Start' section.

supports_color() from #551 answered FORCE_COLOR, the TTY and TERM, but
not NO_COLOR — the variable users actually export globally to opt out of
color (https://no-color.org). Any non-empty value now disables color,
outranking detection and yielding only to an explicit FORCE_COLOR.

Two gaps in the #551 tests are closed alongside. The reload-based tests
recomputed the module constants under a patched environment and left the
last reload's values in place for every test that ran afterwards; a
fixture now re-derives them on teardown. And nothing exercised the copies
commit_check.util binds at import — the ones the print functions actually
read — so two subprocess tests now run the real import path end to end
and assert on what gets printed.