fix(renovate): migrate deprecated match fields and validate strictly

[jimisola]

What & Why

renovate-config-validator --strict exits 1 on this config with "Config migration necessary". Two deprecated fields:

Was	Now
matchPackagePrefixes: ["org.springframework", "org.springframework.security"]	matchPackageNames: ["org.springframework{/,}**", "org.springframework.security{/,}**"]
matchPackagePatterns: [".*"]	matchPackageNames: ["/.*/"]

Both replacements are Renovate's own migration output, taken verbatim from the validator's migration diff rather than hand-translated — so the matching semantics are whatever Renovate itself would have applied at runtime, not my interpretation of the glob and regex forms.

Why it went unnoticed

common-validate-renovate.yml ran the validator without --strict, and a config needing migration exits 0 in that mode. So CI has been green throughout while the config carried deprecated fields that Renovate was silently migrating on every run.

Adding --strict closes that: the next deprecation fails the check instead of passing quietly. Verified both ways locally against the migrated file — exit 0 under --strict, as global config and as repo config.

One observation, deliberately not changed

org.springframework.security{/,}** is redundant — org.springframework{/,}** already matches it, since the {/,} alternation includes the empty case. That redundancy existed identically in the matchPackagePrefixes form, so this PR preserves it rather than quietly changing behaviour during a mechanical migration. Worth removing separately if you agree.

Related

Found while porting this preset to another org, whose trimmed copy passes --strict because the Maven/Gradle rules containing these two fields were dropped as unused. A companion PR adds --strict to that org's validation workflow so both stay honest.

Test Plan

• validate-renovate check passes with --strict now in place
• Confirm the next Renovate run still groups Spring artifacts under spring ecosystem and applies the {{groupId}} packages fallback

[jimisola]

Follow-up commit, same gap found on the companion PR: validate-renovate.yml triggered only on .github/renovate.json5, so a PR editing either validation workflow and nothing else reports no checks at all. This PR happened to touch renovate.json5 too, so the check did run — but a PR adding --strict on its own would have merged unverified.

Added both workflow files to the paths filter. Written out for push and pull_request separately rather than shared via a YAML anchor, since GitHub Actions doesn't support anchors in workflow files.