fix(manager/gradle): add --refresh-dependencies when writing verification metadata

[derekslenk]

Changes

Appends --refresh-dependencies to the command built by buildUpdateVerificationMetadataCmd.

Why: with a warm dependency metadata cache, Gradle skips the parent-POM / platform-BOM hierarchy walk and omits their entries from the written verification-metadata.xml (gradle/gradle#19228, gradle/gradle#20194 — both open for years). Renovate warms that cache systematically: multiple repositories processed through one GRADLE_USER_HOME means every repository after the first regenerates against a warm cache. The written file then reliably misses exactly the parent-POM/BOM .pom/.module entries, and the repository's own CI fails dependency verification on the update PR. The fingerprint is always a recorded .module with a missing .pom, never jars.

Measured with a controlled comparison against a real-world incomplete file (five known-missing entries; every arm reset to the same committed baseline and asserted to start at 0-of-5; warm arms restored from one snapshotted GRADLE_USER_HOME; details in this gradle/gradle#19228 comment):

Arm	Cache	Added (of 5 missing)
current command	warm	0
current command + --refresh-dependencies	warm	5
current command	cold	5
build instead of dependencies	warm	0

The last arm matters for this repo's history: the task token was previously changed to dependencies (#29602, from discussion #29259) — but the writer resolves all resolvable configurations regardless of the named task, so task choice cannot fix or cause this class. Cache state is the whole variable, and only --refresh-dependencies addresses it.

Cost: module descriptors are re-fetched on each regeneration rather than served from cache. In our production use (15 repositories, 4 runs/day, several weeks of PR churn including a 13-branch rebase sweep) the write step runs in 11–22 seconds and we observed no registry rate limiting; the correctness failure it prevents has repeatedly cost human debugging sessions, because an incomplete-but-plausible file fails CI in a way that looks like a repo problem rather than a generation problem.

Context

• This closes an existing Issue, Closes: #
• This doesn't close an Issue, but I accept the risk that this PR may be closed if maintainers disagree with its opening or implementation

AI assistance disclosure

Did you use AI tools to create any part of this pull request?

• No — I did not use AI for this contribution.
• Yes — minimal assistance (e.g., IDE autocomplete, small code completions, grammar fixes).
• Yes — substantive assistance (AI-generated non‑trivial portions of code, tests, or documentation).
• Yes — other (please describe):

Code change, test updates, and this PR text were drafted with Claude (Fable 5) under my direction; I reviewed the change and we validated it in production across a 15-repository fleet before proposing it here.

Use of AI in replying to PR comments

Who answers review comments:

• @username will read and reply directly. Name the account.
• An agent will draft replies and @derekslenk will read them before they are posted. Name the account.
• Nobody has explicitly committed to replying.

Documentation (please check one with an [x])

• I have updated the documentation, or
• No documentation update is required

How I've tested my work (please select one)

I have verified these changes via:

• Code inspection only, or
• Newly added/modified unit tests, or
• No unit tests, but ran on a real repository, or
• Both unit tests + ran on a real repository

The public repository: the validating fleet is private (15 Gradle repositories, self-hosted Renovate 43.288.0); the measurement methodology and results are public in the gradle/gradle#19228 comment linked above. The equivalent preset-level workaround (postUpgradeTasks re-running the same command with the flag) has been in production there since 2026-08-11 with zero recurrences.

[cla-assistant]

All committers have signed the CLA.

[RahulGautamSingh]

LGTM