lint: git-checkout-must-use-github-updates should accept release-monitor as a valid update source

## Problem The `git-checkout-must-use-github-updates` lint rule requires packages using `uses: git-checkout` to configure either `update.github` or `update.git`. However, **`update.release-monitor` is a perfectly valid update source for packages that use `git-checkout`** — the choice of *how to fetch source* and *how to discover new versions* are orthogonal concerns. This is currently **blocking the conversion of ~94 Perl packages** in [chainguard-dev/stereo](https://github.com/chainguard-dev/stereo) from `uses: fetch` to `uses: git-checkout`. The ongoing fetch→git-checkout migration (for build reproducibility) cannot complete for the majority of Perl packages because of this constraint. ## Root Cause Perl uses **decimal versioning** — e.g. `0.018`, `0.21`, `2.006009` — which is not valid semver. This means: - `update.github:` fails `package-version-check` with _"unable to find semver valid tags"_ - `update.git:` satisfies the lint rule syntactically, but is semantically wrong — it's designed for commit-based repos with no versioned releases, not versioned packages - `update.release-monitor:` works correctly (MetaCPAN/CPAN handles Perl versioning natively), but is **rejected by the lint rule** This creates an unresolvable conflict: every valid update source either fails the lint rule or fails the version check. ## Example packages affected In `chainguard-dev/stereo/os/`: - `perl-module-runtime` (version `0.018`) - `perl-scope-guard` (version `0.21`) - `perl-sub-quote` (version `2.006009`) - …and ~91 more Perl packages with `uses: fetch` + `release-monitor` This issue is also why `json-server.yaml` in the same repo has a comment: ```yaml # use git backend here because GitHub backend fails with following message: # failed to create a version slice for typicode/json-server: unable to find semver valid tags ``` ## Suggestions Option A: Relax the `git-checkout-must-use-github-updates` lint rule to also accept `update.release-monitor` as a valid update source. Option B: Allow the `github:` (and/or `git:`) update backend to handle non-semver version tags — e.g. via an opt-in flag like `require-semver: false`. Option A is perhaps simpler in the context of stereo, whereas Option B might be a little more resilient and future proof, but requires more significant back changes....