Fix UpgradeDependencyVersion stabilization with multiple managed dependencies

[timtebeek]

Summary

• Fixes #6321
• Removes premature maybeUpdateModel() call when upgrading non-BOM managed dependencies
• The call was happening before the scheduled visitor had run, causing state inconsistencies when processing multiple managed dependencies with wildcards

What's the problem?

When using UpgradeDependencyVersion("*", "*", "latest.minor", ...) with a POM containing multiple dependencyManagement entries, the recipe required multiple cycles to stabilize. This was because maybeUpdateModel() was called immediately after scheduling the version change via doAfterVisit(), but before the actual change was applied.

The fix

Remove the maybeUpdateModel() call from the managed dependency handling block. The model will be updated naturally when the scheduled visitors run and modify the tree.

Test plan

• [x] Added test upgradeMultipleManagedDependenciesWithWildcards() that verifies multiple managed dependencies can be upgraded with wildcards in a single cycle
• [x] All existing UpgradeDependencyVersionTest tests pass

🤖 Generated with Claude Code

[timtebeek]

This PR has been updated to also

• fix #6322.

Additional changes for #6322:

• Handle BOM imports directly from the tag rather than through findManagedDependency()
• This prevents incorrect matching when a BOM import has the same groupId/artifactId as a dependency managed by another BOM
• Added test upgradeMultipleBomImportsWithWildcards() to verify the fix

The key insight for #6322 was that findManagedDependency() could incorrectly match a dependency managed by the first BOM when processing the second BOM import tag, if both have overlapping dependencies. By checking for BOM imports first and reading the GAV directly from the tag, we avoid this incorrect matching.

[timtebeek]

Reverted to the earlier more minimal change here to make it easier to get this small fix in already.