feat: report code-gauge violations in pull request changes

[exKAZUu]

Requirements

• required: Run the code-gauge check limited to the pull request's changes for every repository through the reusable workflow.
• required: It must not be a merge blocker for now.
• chosen: Two steps in the test job of test.yml, on pull_request events and the first matrix leg only, so callers change nothing and the result does not depend on the Node.js version.
• chosen: The first step, right after checkout, fetches the commit the changes are measured against and passes only its SHA on; the second, after the tests, runs wb code-gauge --base <sha> with no token. The token-using step runs before any pull-request code (installs, build, tests), because such code could otherwise read the token from a process environment or command line, or redirect the step through GITHUB_ENV, GITHUB_PATH, git config, or hooks; and wb executes code installed by the pull request, so the step running it must not hold the token.
• chosen: On a hosted run the checkout is the pull-request merge commit, so the base is its first parent (fetched with depth 2): the comparison stays exact when the base branch moved or was rewritten after the merge commit was built. On a self-hosted run the checkout is the head branch tip, so the compare API gives the merge-base and how many commits HEAD is ahead, and one git fetch --depth=<ahead + 1> reaches it. --shallow-exclude would fetch less, but it left a broken shallow repository in a trial whenever a fetched commit merges the base branch.
• chosen: The fetch authenticates with github.token, the token the checkout itself uses: it is read-only on fork pull requests, which is enough. It is passed to git through GIT_CONFIG_* variables for that one command.
• chosen: The first step does nothing unless package.json declares @willbooster/wb, and the report step does nothing unless wb code-gauge --help lists --base, because callers pin many wb versions and older ones lack the command.
• chosen: The report runs after the tests even when they failed (!cancelled()), after the build because a repository that develops wb runs it from its build output, and before lint-staged and the release test because they modify and stage files that code-gauge would count as changes. It measures the tree the fix step left: formatting does not change code-gauge's metrics, and a pull request the fixers modify already fails the job.
• chosen: wb is run as node_modules/.bin/wb, not through the package manager, because Yarn 1 wraps the output in its own lines and the summary must stay empty when there are no violations. A Yarn Plug'n'Play caller therefore gets no report; none exists among the callers.
• chosen: Expected failures (API or fetch failure, no base commit) end the step successfully with a notice annotation; a wb that exits non-zero gets a warning annotation and a summary heading saying it failed; continue-on-error and timeouts cover everything else, so the job result never changes.

Self Check

• I've confirmed All checks have passed on this page.
• I've reviewed my changes on the GitHub diff view.
• I've written the steps to test my changes.
• I've added screenshots (if the UI changed).

Steps to Test

1. bun verify and actionlint with the flags of lint-workflows.yml pass locally.
2. The fetch step's script, extracted from the workflow file, was run with bash in both modes against shallow clones of this pull request (its merge commit, and its head branch tip): each found the base commit, and git diff against it listed exactly the pull request's file.
3. On GitHub Actions (hosted runner, public repository): a throwaway draft pull request in a caller repository pointed its workflow at this branch, used wb 22.19.0, and added one violating function. Both steps succeeded and the job log showed code-gauge: 1 threshold violations (...) with the added function; the job stayed green.
4. With wb 22.18.0, without wb, and without package.json the script prints nothing and exits 0 (checked locally on the first revision of the step).

Notes

• Not exercised on GitHub Actions: a self-hosted runner (the compare API path, and git 2.31 or newer for GIT_CONFIG_COUNT) and a private repository. A failure there only costs the report.
• A run whose tree was already tested is skipped as a duplicate by the existing skip logic, and these steps with it.

[gemini-code-assist]

Warning

You have reached your daily quota limit. Please wait up to 24 hours and I will start processing your requests again!