upper-bounds for libraries from Jenkins core should not be bumped past their version in Jenkins

### What feature do you want to see added?

The upper-bounds fixer in the PCT aligns all dependencies to the highest version under test.

However this is incorrect for libraries that come from core as the library version they get at runtime will always be the version from core. So using a newer version (that comes from elsewhere in the dependency tree) will be incorrect and lead to issues where hooks are needed for these cases (e.g. https://github.com/jenkinsci/plugin-compat-tester/pull/733).
Instead the version that is used in alignment should be the version from the Jenkins core.

If a plugin is using a plugin-first classloader then bumping the version will update the library when it wouldn't have that at runtime, or mask classes, but these plugins are the exception to the general, so the PCT should cope for the general use case, and hooks should exist only for the non general.

An Argument could be made that plugins should excluded any transitive dependency from libraries so that they always only come from core and would then not be visible in the upper-bounds fixer.

### Upstream changes

_No response_

### Are you interested in contributing this feature?

_No response_

Start at the PCT upper-bounds fixer and compare its behavior with the case described in pull request 733. Trace how Jenkins core library versions are identified and used during alignment, including the plugin-first classloader exception. Done means core-provided libraries are not aligned beyond their Jenkins core versions while exceptional cases remain supportable.

Written by the indexing model from the issue text.