Add Renovate config (Gradle + Docker)

[jonbartels]

Supersedes the Dependabot approach in #356.

Summary

Adds renovate.json to configure Renovate for dependency updates. No custom workflow is needed — Renovate maintains the Gradle dependency-verification metadata itself (see below).

renovate.json

• Base: config:recommended
• Schedule: monthly, America/New_York
• minimumReleaseAge: "2 days" — waits before opening a PR (skips yanked/broken releases)
• Grouping by coherent project family, keyed deep so unrelated org.apache.* projects stay separate (org.apache.commons, org.apache.logging.log4j, …): aws-sdk, jetty, jersey, jackson, netty, log4j, apache-commons, test-tooling, plus a catch-all all-minor-and-patch. Rule order accounts for Renovate's last-match-wins merge so family groups aren't swallowed by the catch-all.
• Noise/safety: prConcurrentLimit: 10, prHourlyLimit: 2, ecosystem labels (java/docker), semantic commits, dependencyDashboard, osvVulnerabilityAlerts
• Majors require Dependency Dashboard approval (major.dependencyDashboardApproval: true)
• automerge: false — never automerge
• Docker Dockerfile handled automatically by Renovate's dockerfile manager

Gradle dependency verification — handled by Renovate, no workflow

This repo enforces gradle/verification-metadata.xml (verify-metadata=true). Renovate's Gradle manager detects that and runs ./gradlew --write-verification-metadata sha256 dependencies, committing the refreshed checksums in its own PR.

This was verified empirically on a live Mend-hosted fork: on a genuinely-needed update (org.eclipse.jetty:jetty-http → 10.0.0), Renovate committed the catalog bump and the new jar/pom/parent-POM checksums in a single renovate[bot] commit (origin="Generated by Gradle"), with no helper workflow present. An earlier draft of this PR carried a split-privilege regen workflow; it turned out to be unnecessary (it only looked required because its push-triggered commit raced Renovate's own artifact update). That workflow has been removed.

⚠️ Manual configuration (repo admin)

1. Install the Mend Renovate GitHub App on the repo and merge its onboarding PR.
2. Labels dependencies / java / docker already exist — no action.
3. No dependabot.yml exists on main; ensure no org-level Dependabot config double-runs updates.

🤖 Generated with Claude Code

[github-actions]

Test Results

654 tests  ±0   654 ✅ ±0   3m 44s ⏱️ + 1m 1s
108 suites ±0     0 💤 ±0 
108 files   ±0     0 ❌ ±0 

Results for commit 73213dd. ± Comparison against base commit a08c114.

♻️ This comment has been updated with latest results.

[jonbartels]

Here is an example of what we get out of renovate. https://github.com/jonbartels/oie-engine/pulls/app%2Frenovate

This doesn't do the grouping like dependa does I'll work on configuring it.

[kpalang]

Looks alright, lets see what we get.

[pacmano1]

Read the config against the version catalog and the repo's labels. The verification-metadata
story is the right solution to the problem demonstrated on #356, and the empirical run on the
live fork is the evidence that matters. Four items, none of them blocking.

1. Catch-all scope, question. The all-minor-and-patch rule matches on update type only,
   and config:recommended also enables the dockerfile and github-actions managers (the root
   Dockerfile and the two workflows). Won't a monthly run pull a base-image bump and an actions
   bump into the same group PR as the gradle patches, with merged labels? If that's not
   intended, "matchManagers": ["gradle"] on the catch-all would scope it. If your fork run
   already showed separate PRs, ignore this.

2. App install ownership. Merging this is a no-op until the Mend app is installed, and the
   failure mode is pure silence, no dashboard, no PRs, no error. Who owns the install? Suggest
   doing it after merge so Renovate detects the existing config and skips onboarding, then
   posting here once the Dependency Dashboard issue appears. That's the same-day confirmation
   the wiring is live, instead of waiting a month to notice nothing happened.

3. Description fix. The catch-all description says majors stay individual. That's true only
   for deps no family rule matches. The family rules have no matchUpdateTypes, so an approved
   jetty major rides the jetty group branch with any pending minors. Grouping family majors
   is arguably correct, those move in lockstep, but the description should say what actually
   happens: ungrouped majors stay individual, family majors ride their family group. Same
   overstatement is in the PR body.

4. For the record, on reviewing future Renovate PRs. Since Renovate regenerates
   gradle/verification-metadata.xml from whatever it downloads, the checksum file is not an
   independent check at bump time. It still pins artifacts against later tampering, but at bump
   time the control is the diff review. Review rule going forward: the metadata diff on a
   Renovate PR should only touch entries for the artifacts being bumped, unrelated churn in
   that file is the thing to stop on. The 2-day minimumReleaseAge covers the yanked-release
   window. And per the race documented in this PR's body, no regen workflow should be added
   back later, Renovate maintains the file itself.