Remove consumer-side dependency filtering workarounds for uninterpolated expressions

[gnodet]

Summary

Companion PR to apache/maven-resolver#1957, which adds re-entrancy detection to DefaultRepositorySystem. With the resolver now skipping validation on re-entrant calls, the consumer-side workarounds that filtered dependencies with uninterpolated ${…} expressions are no longer needed.

⚠️ Depends on: This PR must be merged after apache/maven-resolver#1957 is merged and the resolver dependency in Maven's pom.xml is updated to include the re-entrancy fix. Until then, the MavenITgh12305 integration test will fail (expected — it tests the exact scenario these workarounds protected against).

Removed workarounds (all purely defensive against MavenValidator rejection on re-entry):

• DefaultArtifactDescriptorReader: dependency and managed dependency filtering in populateResult() and filterUninterpolated()
• ArtifactDescriptorReaderDelegate (compat): dependency and managed dependency filtering in populateResult()
• DefaultProjectDependenciesResolver: managed dependency placeholder check before collectDependencies()
• DefaultDependencyResolver: enhanceCollectionError() for "Invalid Collect Request" with unresolved expressions (error path no longer reachable)

Kept: Repository filtering (URLs with ${…} are genuinely invalid — you can't connect to them).

This is a net deletion of ~116 lines of workaround code across 4 files.

Context

These workarounds were introduced across several PRs (#12049, #12084, #12204, #12305) to work around the fact that Maven 4's MavenValidator rejected artifacts with uninterpolated expressions during re-entrant RepositorySystem calls (model builder → model resolver → RepositorySystem chain). The resolver fix addresses this at the source by detecting re-entrancy via RequestTrace ancestry and skipping validation on inner calls.

IT failure analysis

The MavenITgh12305InvalidCollectRequestUninterpolatedManagedDepsTest IT fails because it tests building a project that imports a BOM with uninterpolated ${osgi.version} in managed dependencies. Without either the consumer-side workarounds (removed here) or the resolver-side re-entrancy fix (not yet in Maven's resolver dependency), the MavenValidator rejects the expression. Once Maven's resolver dependency is updated to include the re-entrancy fix, this IT will pass without the workarounds.

Test plan

• mvn test -pl compat/maven-resolver-provider — all tests pass
• mvn test -pl impl/maven-impl — all tests pass
• mvn test -pl impl/maven-core — all tests pass
• CI: only MavenITgh12305 IT fails (expected — needs resolver fix integrated)
• Full CI after resolver dependency update

🤖 Generated with Claude Code