Fix #12983: ToolchainPluginStrategy handles inherited source levels

[gnodet]

Summary

• Adds effective model resolution as a fallback when ToolchainPluginStrategy finds no source level in the local POM DOM
• When maven.compiler.source/target is inherited from a parent POM (e.g., geronimo-genesis sets source=1.5), mvnup now resolves the effective source level via buildEffectiveModel() and configures the auto-toolchain for JDK 8/11 compilation
• This fixes the 12 Apache projects (ftpserver, geronimo-genesis, aries-tx-control, etc.) that fail with "Source option N is no longer supported" under Maven 4

Design

The fix follows the same pattern used by CompatibilityFixStrategy.collectEffectiveProperties():

1. Fast path (unchanged): inspect the local POM DOM for maven.compiler.release, maven.compiler.source, or compiler plugin config
2. Fallback path (new): if the fast path returns -1, build the effective Maven model which resolves all inherited properties from parent POMs, then check maven.compiler.release and maven.compiler.source from the effective properties
3. Failures in effective model resolution are caught and logged at debug level — the strategy degrades gracefully

Test plan

• Unit tests for detectSourceLevelFromEffectiveModel() (6 tests): release property, source property, precedence, legacy 1.x format, empty properties, no compiler properties
• Integration-style tests for doApply() with inherited source levels (5 tests): plugin added for inherited incompatible source, no modification for compatible inherited source, graceful fallback on resolution failure, local takes precedence over effective, correct JDK constraint (source 6 → JDK 11)
• All 31 tests pass, format check passes

🤖 Generated with Claude Code

[gnodet]

Closing as duplicate of #12973, which fixes the same issue (inherited source level detection in ToolchainPluginStrategy) and also includes session caching improvements via MvnupSessionHolder and RequestCache deduplication.