feat: add file metadata checks (CC302-CC304) - #560

GitHub's push rules police file size, path patterns and path length,
but only on Team and Enterprise plans for private repositories; this
brings the same policies to every plan and forge (#558). The need is
first-party: this organization once shipped a GitHub App private key
committed as a *.pem, and a prohibited-pattern rule would have
stopped it at commit time.

Three independent rules join the CC3xx range, all off until their
[files] setting carries a usable value:

* CC302 file_size — commits may not add files over max_size (bytes,
  or a KB/MB/GB suffix; binary units)
* CC303 file_pattern — committed paths may not match any
  prohibited_patterns fnmatch entry; a bare pattern like *.pem also
  matches the file name at any depth
* CC304 path_length — committed paths may not exceed
  max_path_length characters

--files (-f) requests them for the commit at HEAD or --rev, reading
only the paths and sizes recorded in the commit — never contents,
keeping the "not a code linter" promise (content scanning stays with
tools like gitleaks). Deletion-only commits skip: removing a file
adds nothing to police. Malformed config values disable a rule
rather than failing every commit, and --files with an empty [files]
section says so on stderr instead of passing silently. A check-files
pre-push hook covers the tip commit locally; CI covers every commit.

Closes #558

The path-length pass path, the unknown-check defensive fallthrough,
the unconfigured --files hint, and the ls-tree-failure branch in
get_commit_files each lacked a test; patch coverage now reports the
new modules at 100%.

Three review findings, each verified before fixing:

* The check-files pre-push hook validated HEAD, so pushing another
  local ref passed CC302-CC304 without checking what was pushed.
  FilesValidator now recognizes the four-field pre-push ref lines on
  stdin and validates the tip of every pushed ref (deletions exempt);
  input of any other shape falls back to the revision under test.
* parse_size("inf") aborted the whole run with OverflowError instead
  of disabling CC302 as documented — int(float("inf")) raises it and
  only ValueError was caught.
* _build_files_rules carried cognitive complexity 27 against the
  configured limit of 15 (the one SonarCloud finding on this PR);
  the three rule-specific branches are now focused builders and the
  method is a dispatcher.

README documents the check-files hook alongside check-tag.

Code review found the file rules reporting pass or skip while a
violating file sat in the commit. Each was reproduced end to end in a
scratch repo before and after the fix:

* git ls-tree reads pathspecs relative to the current directory, so
  running commit-check from any subdirectory matched zero entries and
  every file rule skipped with exit 0 on a commit that failed at the
  repository root. Pathspecs are now :(top,literal) and the lookup is
  --full-tree, which also keeps the paths root-relative -- otherwise
  CC303 matches and CC304 lengths would be measured against '../x'.
* git diff-tree prints nothing for a merge commit, so a prohibited
  file arriving through a merge passed unexamined -- exactly the
  commit CI checks on a pull request. Merges are now diffed against
  their first parent.
* The pre-push hook reduced each ref to its tip, so a .pem added by
  any earlier commit of a multi-commit push went through. The remote
  sha on the hook's stdin line now bounds a rev-list range, and files
  repeated across commits collapse to one offender.
* A failed ls-tree batch was skipped, silently shrinking the checked
  set while the run still passed. A failure now reports nothing, which
  surfaces as a skip rather than a pass, and batches are bounded by
  argument length as well as count so Windows' 32k command line cannot
  drop a batch in the first place.

Two more, found the same way:

* Pushing a tag re-diffed the commit it points at, so git push
  --follow-tags could be rejected over a file committed months ago.
  Tag refs are skipped here; CC401 polices tag names.
* An unusable [files] value (max_size = "5M") disabled its rule in
  silence whenever another file setting was valid, since the
  "nothing configured" hint only fires when no rule builds at all.
  The rejected setting and its value are now named on stderr.

get_commit_files is memoized per run on the context, so the three
rules share one lookup instead of running the git plumbing three
times over every commit in a push.

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

Review caught a hole in the previous commit: skipping refs/tags/* on
pre-push assumed a tag always names history that was already pushed.
When no pushed branch contains the tagged commit, the tag push is what
delivers it, and a prohibited file rode along with exit 0. Reproduced
against a real remote before and after.

Tags now go through the same range as branches. What matters is not
whether a ref is a tag but whether it carries commits the remote
lacks, and rev-list answers that either way: a tag over already-pushed
history resolves to an empty range, so git push --follow-tags is still
not rejected over a file committed long before, while a tag that is
the only thing carrying a commit gets that commit checked. Verified
all three: unpushed-commit tag fails, already-pushed tag passes, and a
branch+tag push fails once rather than twice.

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