fix: resolve merge-base refs that exist only on the remote - #532

* fix: treat an empty commit message as supplied, not absent

main went red on the push run right after #532 merged, on a test that
had been green on the pull request. Nothing regressed -- the merge was
the first time the test met a real commit.

_get_commit_body tested stdin_text for truth, so an empty string read
as "not provided" and the check fell through to get_commit_info("b"),
the repository's HEAD commit. test_empty_message_passes therefore never
measured an empty message: on a pull_request run HEAD is GitHub's
synthetic merge commit, whose body is empty, so it passed for the wrong
reason; on main HEAD became the squashed commit carrying a
Co-authored-by trailer, CC013 detected it, and the test failed. Measured
on this checkout, the "empty" message resolved to 6694 characters.

The same looseness reaches the public API: validate_message("") answers
about the last commit rather than the empty message it was given.

The skip logic in this file already draws the line at None
(_should_skip_validation, _resolve_current_author); _get_commit_body now
follows it. The CLI is unaffected -- _resolve_commit_message_source
already normalises empty stdin to None.

Adds a hermetic regression test: the existing one only holds while the
checkout's own HEAD carries no AI trailers, which is what made it fragile
in the first place. The new one patches get_commit_info and asserts it is
never consulted.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01U9zFxq8V4qxG4aMzJhGBFn

* fix: distinguish an absent commit message from an empty one

Follows the one-line fix on _get_commit_body by applying the same rule
to the readers that were still testing stdin_text for truth, so an
empty string is no longer read as "the caller said nothing".

_get_commit_message, _get_subject, _get_author_value and BranchValidator
now split on None, matching _should_skip_validation and
_resolve_current_author, which already did. api.validate_author draws
the same line with `name is not None`, so the intent was there; only
these readers had not followed it. ForcePushValidator deliberately keeps
a truth test: its stdin_text carries a *list* of refs, where empty
genuinely means nothing to check rather than a value to judge.

That surfaced a rule that could never fire. _is_empty_commit_allowed
exists to reject an empty message under allow_empty_commits = false, but
CommitTypeValidator returned PASS on a falsy message before ever
reaching it, so the rejecting branch was dead code. A supplied message
now reaches the rule even when empty; one git never gave us still
returns early. Measured after the change:

    validate_message("")                          -> pass  (default)
    validate_message("", allow_empty_commits=off) -> fail  CC008

The other validators keep their early return: BodyValidator documents
whitespace-only input as "no commit message at all", and
allow_empty_commits is the rule that owns that judgement.

Adds two tests pinning both directions, each patching get_commit_info to
prove the verdict comes from the supplied message rather than the
repository's HEAD. Restoring the early return fails them.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01U9zFxq8V4qxG4aMzJhGBFn

* docs: record why an unreadable commit file still counts as named

Review asked whether _message_was_supplied should drop to False when a
commit_file cannot be read, since the text then comes from git. Measured
the only reachable case: a HEAD commit whose message is genuinely empty,
where allow_empty_commits = false makes CC008 the correct verdict.
Deriving the flag from successful resolution would restore the miss this
branch fixes, so the behaviour stands and the docstring now says why.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01U9zFxq8V4qxG4aMzJhGBFn

---------

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

The pin was v2.13.0, whose requirements.txt installs commit-check 2.13.1.
That engine cannot resolve a rebase target existing only as origin/main in
a pull request checkout, so it reported "not rebased" for a branch that
was -- the false CC202 this workflow has carried since its first run.

v2.13.1 of the action installs commit-check 2.13.4, which carries the
merge-base fix from #532. Confirmed by reading requirements.txt at the tag
rather than assuming the action version tracks the engine version:

    v2.13.0 (124de73) -> commit-check==2.13.1
    v2.13.1 (562a184) -> commit-check==2.13.4

The branch was already rebased before this change -- git merge-base
--is-ancestor origin/main HEAD returned true while CC202 still failed --
so the failure was the engine, not the branch, and rebasing again could
never have fixed it.

Two things ride along on the newer engine. Skipped checks now report as
skipped rather than as passes (#537), so a run bypassed by ignore_authors
says so instead of showing green ticks over nothing. And the imperative
whitelist goes from 396 verbs to 529, retiring a class of false CC003 --
2.13.1 rejected "treat", which #527 had added three releases earlier.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01U9zFxq8V4qxG4aMzJhGBFn