Fix concurrent updates to mapped model sources

[goutamadwant]

Fixes #12597.

mappedSources uses a ConcurrentHashMap, but its values were ordinary
HashSet instances. Parallel model discovery could therefore lose sources
when multiple tasks updated the same group/artifact index.

Use ConcurrentHashMap.newKeySet() for each mapped source set. This preserves
duplicate suppression while making concurrent updates and iteration safe.

Regression coverage exercises concurrent writes to both the direct
group/artifact key and the secondary null-group key, verifies concurrent
collection semantics and multi-source lookup behavior, and preserves duplicate
suppression.

A backport to maven-4.0.x may be appropriate.

Tests:

• mvn -pl impl/maven-impl verify (552 tests passed, 4 skipped)
• mvn -Prun-its verify under Java 21 (all 1,051 Core ITs executed)
• Targeted Java 21 rerun of the two previously toolchain-sensitive IT classes
  (4 tests passed)

The full Core IT run reported two stale generated-file errors in toolchain
tests and one existing MNG-8181 log-format assertion. None exercises the
changed model-source code.

• Your pull request should address just one issue, without pulling in other changes.
• Write a pull request description that is detailed enough to understand what the pull request does, how, and why.
• Each commit in the pull request should have a meaningful subject line and body.
• Write unit tests that match behavioral changes, where the tests fail if the changes to the runtime are not applied.
• Run mvn verify to make sure basic checks pass.
• You have run the Core IT successfully. See the test details above.
• I hereby declare this contribution to be licenced under the Apache License Version 2.0, January 2004.
• In any other case, please file an Apache Individual Contributor License Agreement.

[gnodet]

APPROVE ✅

Clean, minimal fix that correctly replaces a thread-unsafe HashSet with ConcurrentHashMap.newKeySet() for the inner set values of a ConcurrentHashMap, accompanied by well-structured concurrency and deduplication tests.

Observations (non-blocking):

1. The one-line production change is correct and complete. The outer ConcurrentHashMap.computeIfAbsent is atomic for creating the entry, and the inner ConcurrentHashMap.newKeySet() makes the returned Set thread-safe for concurrent add and iteration.

2. The resolveReactorModel method iterates the set with a for-each loop. With ConcurrentHashMap.newKeySet(), this produces a weakly consistent iterator that will not throw ConcurrentModificationException, which is the correct behavior for this use case.

3. PathSource.equals/hashCode (based on Path) ensures that deduplication semantics are preserved with the new ConcurrentHashMap-backed set, matching the previous HashSet behavior.

4. The HashSet import remains used elsewhere in the class (lines 987, 1519), so the import is still needed.

This review was generated by an AI agent (Claude Code) and may contain inaccuracies. Please verify all suggestions before applying.

Claude Code on behalf of Guillaume Nodet