feat: add Bazel (bzlmod) MODULE.bazel ecosystem checker

[algomaster99]

Summary

• Adds pkg/bazel, checking bazel_dep entries in MODULE.bazel against the Bazel Central Registry's latest release, via git-pkgs/manifests + an injected resolver.Resolver.
• Prioritized (see Add more ecosystems (Cargo, RubyGems, Composer, NuGet, CocoaPods, Bazel, Go, GitHub Actions) #4) because there's no bazel add-style command that resolves a module's latest release and writes it into MODULE.bazel — a bazel_dep(name = ..., version = ...) entry is always hand-typed, unlike ecosystems with a cargo add/go get/npm install equivalent.
• bzlmod's dependency format has no range syntax, so every bazel_dep version is already an exact pin — same shape as go.mod's require entries.
• Wired into newCheckers/checkerFor in main.go, covered by unit tests, and added to benchmark/cases.json (4 fresh + 1 existing).

Before: no MODULE.bazel support — a stale bazel_dep version pin passes through unchecked.

After:

outdated dependencies, use these versions instead:
  rules_go  0.41.0 -> 0.50.1

---

Generated by Claude Code

[algomaster99]

Ran the 5 bazel-* benchmark cases (hook + nohook) against a freshly rebuilt yul binary — results and transcripts pushed in this branch under benchmark/runs/bazel-*/.

Blocking mechanism confirmed working — the hook correctly caught and forced a version bump in 3/5 cases:

case	hook final	nohook final	blocked?
curl	8.21.0	8.21.0.bcr.1	yes
nlohmann_json	3.12.0	3.12.0.bcr.2	yes
googletest	1.18.0	1.18.0.bcr.1	yes
glog	0.7.1	0.7.1.bcr.1	no
protobuf	21.7	36.0	no

Two resolver-data gaps surfaced, not bugs in the blocking logic itself:

1. .bcr.N suffix blindness: the resolver's "latest" always comes back as the bare upstream version (e.g. 8.21.0) and never BCR's own patch suffix (8.21.0.bcr.1), which is the actual latest release on the registry. This was harmless for curl/nlohmann_json/googletest since the base version alone was enough to trigger a block, but for glog the pin (0.7.1) already matched the resolver's truncated "latest" exactly, so the hook stayed silent while the true latest (0.7.1.bcr.1) slipped through.

2. protobuf false negative: pinned at 21.7, real BCR latest is 36.0, hook never blocked. Traced this to git-pkgs/enrichment's pkg:bazel/protobuf lookup resolving to 3.19.6 — protobuf's old pre-2022 versioning scheme, not the Bazel Central Registry's module version scheme (21.x→36.x). Since 21.7 > 3.19.6, the checker sees the pin as already ahead of "latest" and never flags a 15-major-version gap.

Both are git-pkgs/enrichment purl-resolution issues for pkg:bazel/*, not something fixable in pkg/bazel/bazel.go.

[andrew]

@algomaster99 please report issues like this in the relevant git-pkgs repos as well so I can keep track of them

[algomaster99]

Good idea @andrew ! I will open the issue for these two cases.

[algomaster99]

Added the issue: git-pkgs/enrichment#65.