Resolve with effective Maven settings in recipes

[pdelagrave]

What's changed?

Recipes that construct their own MavenPomDownloader (UpdateMavenModel, ChangeParentPom, RemoveRedundantDependencyVersions, RemoveUnusedProperties, RemoveRedundantProperties, ParentPomInsight, MavenDependencyPropertyUsageOverlap, and MavenDependency's exact-version fallback) passed the raw LST-carried settings, or none at all, to the downloader. A new MavenPomDownloader#forResolutionResult factory combines the LST-carried settings with those on the execution context, and every such call site now uses it (or effectiveSettings directly where a caller-supplied project poms map is load-bearing). FindRepositoryOrder gets the same treatment on the getRepositories path.

A recipe-level test is added to MavenCentralMirrorTest: an LST produced without any mirror, resolved by a recipe under an execution context that carries one, must route all parent pom traffic through the context's mirror. The test fails if any converted call site regresses to passing raw LST settings.

What's your motivation?

Mirrors and repositories supplied on the execution context at run time were silently ignored during parent pom, metadata, and repository-order resolution in these recipes: the settings argument of MavenPomDownloader replaces, rather than combines with, the settings on the execution context. MavenVisitor and UpgradeDependencyVersion already resolved with the effective settings; this aligns the remaining call sites and gives the pattern a single named entry point so the next recipe gets it right by default.

Any additional context

• Builds on Fix MavenSettings value equality dropping LST-carried mirrors #8189, which makes the settings equality underlying effectiveSettings meaningful; the base branch is set accordingly and this PR should be retargeted or rebased once Fix MavenSettings value equality dropping LST-carried mirrors #8189 merges.

Checklist

• I've added unit tests to cover both positive and negative cases