renovate: don't flag packageRules covered by a top-level minimumReleaseAge

[munzzyy]

Link to an issue, if relevant

Fixes #3995

Summary

renovate-missing-minimum-release-age only looks for minimumReleaseAge inside each packageRules entry. Renovate applies a top-level minimumReleaseAge to every package, so a config like this is fully protected but still gets one finding per entry:

{
  "minimumReleaseAge": "7 days",
  "packageRules": [
    { "matchPackageNames": ["webpack"], "groupName": "Webpack build system" }
  ]
}

This adds a pattern-not-inside to branch 1 (the "missing entirely" branch) that suppresses the finding when the object holding packageRules also sets a string minimumReleaseAge. Two details were deliberate:

• The suppression requires a string value ("minimumReleaseAge": "$TOPAGE"), so a top-level "minimumReleaseAge": false does not silence the rule. The global-false test file covers this.
• Branches 2 and 3 are untouched. An entry that overrides the global value with something too low ("3 days") or malformed ("banana days") is still flagged, which matches Renovate's semantics: a packageRules value replaces the global one for the packages it matches.

What I tested

semgrep test package_managers/renovate and semgrep validate with semgrep 1.169.0. All existing cases in renovate-missing-minimum-release-age.test.json still pass. The three new test files fail against the unpatched rule (on exactly the two false-positive lines) and pass with the patch. It takes three files because a top-level key applies to the whole file, so the scenarios can't share a fixture: global age before packageRules, global age after it, and global false.

Known limits

• A top-level value that is a string but too low (say "2 days") also suppresses the per-entry findings. As far as I can tell semgrep has no way to attach a metavariable condition to a pattern-not-inside, so catching a weak top-level value would need a new branch that inspects it directly. I can add that here if you want it, but it seemed like a separate decision from fixing the false positive.
• Presets pulled in via extends (the reporter's original setup) can't be resolved statically, so a preset-provided global age still gets flagged. The issue's own suggestion was to handle the explicit top-level key, which is what this does.

I left the rule message alone since #3885 already rewrites it.

[CLAassistant]

All committers have signed the CLA.