fix(github): don't abort scorecard run on 422 from commit search

[pujitha24]

What kind of change does this PR introduce?

Bug fix.

• PR title follows the guidelines defined in our pull request documentation

What is the current behavior?

The Dependency-Update-Tool check calls GitHub's commit search API to look for
dependabot[bot] commits. Some public repositories (not yet indexed by GitHub
search) and GitHub Enterprise Server instances return 422 Validation Failed
for this otherwise-valid query. That 422 is currently propagated as a hard
error, which aborts the entire scorecard run with check runtime error: Dependency-Update-Tool: internal error: dependabot commit search: ..., even
though every other check already finished successfully.

What is the new behavior (if this is a feature change)?

searchCommitsHandler.search now detects a 422 Unprocessable Entity
response from Search.Commits and returns an empty commit list with no
error, instead of a hard error. This mirrors the existing handling of
clients.ErrUnsupportedFeature a few lines away in
checks/raw/dependency_update_tool.go, which already treats "can't search
commits" as "assume no commit-search-based tools were found" rather than
failing the whole run. Also fixed an unrelated copy-paste typo in the wrapped
error message (Search.Code -> Search.Commits, since this call is
Search.Commits).

• Tests for the changes have been added (for bug fixes/features)

Which issue(s) this PR fixes

NONE

Special notes for your reviewer

Validation: added TestSearchCommitsHandles422, which mocks a 422 HTTP
response and asserts search() returns no error and zero commits. Confirmed
this test fails on the pre-fix code (reproducing the reported
"Search.Code: 422 Validation Failed" error) and passes after the fix.

Commands run:

• go build ./...
• SKIP_GINKGO=1 go test -race ./clients/githubrepo/... ./checks/raw/... (matches CI's make unit-test)
• golangci-lint run -c .golangci.yml --new-from-rev=HEAD ./clients/githubrepo/... (0 new issues)

This only changes the client's error handling for a specific HTTP status
code; user-visible check results for repos that don't hit this 422 are
unchanged. For repos that do hit it, Dependency-Update-Tool will now
complete (falling back to file-based detection, e.g. .github/dependabot.yml)
instead of aborting the whole scorecard run.

Does this PR introduce a user-facing change?

For user-facing changes, please add a concise, human-readable release note to
the release-note

(In particular, describe what changes users might need to make in their
application as a result of this pull request.)

Fixed a bug where the Dependency-Update-Tool check could abort the entire
scorecard run with a "422 Validation Failed" error from GitHub's commit
search API, which occurs for some public repositories and on GitHub
Enterprise Server. The check now completes gracefully, falling back to
file-based detection.

Fixes #4352

[codecov]

Codecov Report

❌ Patch coverage is 80.00000% with 1 line in your changes missing coverage. Please review.
✅ Project coverage is 70.15%. Comparing base (353ed60) to head (5bf7929).
⚠️ Report is 373 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #5181      +/-   ##
==========================================
+ Coverage   66.80%   70.15%   +3.34%     
==========================================
  Files         230      252      +22     
  Lines       16602    15865     -737     
==========================================
+ Hits        11091    11130      +39     
+ Misses       4808     3848     -960     
- Partials      703      887     +184     

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[pujitha24]

Just checking in on this one — it's rebased on main and all checks are green. Happy to make any changes if something would help move review along.