[Bug] _api raises without naming the request path, so the 422 in Contributor Reputation Check cannot be located #56

What happens

Contributor Reputation Check / check fails on main with:

Error: contributor_check.py exited 1: urllib.error.HTTPError: HTTP Error 422: Unprocessable Entity

That is the whole diagnostic. The error names a status and nothing else, so there is no way
to tell which of the run's API calls produced it.

Observed on the CI run for #49. The job runs on pull_request_target and checks out base
main, so it is not caused by that PR.

Why it is not visible day to day

The job's if: skips the maintainer account, so it only runs on pull requests from everyone
else. #49 was the first external PR to exercise the vendored path since #46 landed, and it
failed. The next external PR will fail the same way.

What is already ruled out

The full profile check was traced locally against the same username and the same
--target-repo, 29 API calls across /users, /users/*/repos, /search/issues,
/repos/*/pulls, /users/*/orgs, /orgs/*/repos and /repos/*/contributors. Every call
returned 200, including both /search/issues queries. So it does not reproduce with a user
token, which points at the Actions GITHUB_TOKEN identity rather than at the query shape.
Without the path in the error there is no way to narrow it further from the log.

Proposed fix

#49 established the convention that an exhausted path names its cause on stderr before
raising, because _run_check surfaces the last stderr line. None of those lines names the
call. Adding the path would make the existing convention diagnostic rather than descriptive:

• the three cause lines carry path alongside the status or reason
• the final raise for any other HTTP status gets a cause line of its own, which it currently does not have

That is the branch a 422 takes today, and it is the only one that prints nothing at all.