Fix BUILD_CONSUMER profile activation for locally-resolved parent POMs

[DavidTavoularis]

Fixes #11798

When readParentLocally() finds a parent via resolveReactorModel() during BUILD_CONSUMER processing, derive(candidateSource) preserves the BUILD_CONSUMER request type. Since isBuildRequestWithActivation() returns false for BUILD_CONSUMER, POM profile activation is skipped for all parent POMs in the chain, leaving profile-defined properties (like BOM import versions) unresolved.

In contrast, resolveAndReadParentExternally() correctly creates a CONSUMER_PARENT request which allows profile activation.

The fix ensures readParentLocally() also uses CONSUMER_PARENT when the current request is BUILD_CONSUMER, consistent with the external resolution path.

Following this checklist to help us incorporate your
contribution quickly and easily:

• 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.
  Note that commits might be squashed by a maintainer on merge.
• Write unit tests that match behavioral changes, where the tests fail if the changes to the runtime are not applied.
  This may not always be possible but is a best-practice.
• Run mvn verify to make sure basic checks pass.
  A more thorough check will be performed on your pull request automatically.
• You have run the Core IT successfully.

If your pull request is about ~20 lines of code you don't need to sign an
Individual Contributor License Agreement if you are unsure
please ask on the developers list.

To make clear that you license your contribution under
the Apache License Version 2.0, January 2004
you have to acknowledge this by using the following check-box.

• 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]

Review

Clean and well-targeted fix. The asymmetry was clear:

• resolveAndReadParentExternally() → uses CONSUMER_PARENT → profiles activate ✓
• readParentLocally() → inherits BUILD_CONSUMER → profiles skipped ✗

The fix makes them consistent. The test POM fixtures are minimal and clearly reproduce the issue.

Minor style suggestion: The if/else block could be slightly simplified:

ModelBuilderRequest parentRequest = request.getRequestType() == ModelBuilderRequest.RequestType.BUILD_CONSUMER
        ? ModelBuilderRequest.builder(request)
                .requestType(ModelBuilderRequest.RequestType.CONSUMER_PARENT)
                .source(candidateSource)
                .build()
        : ModelBuilderRequest.build(request, candidateSource);
derived = derive(parentRequest);

But that's a style preference, not a correctness concern.

This PR depends on #11768 and should merge after it. Looks good overall.

Claude Code on behalf of Guillaume Nodet

[DavidTavoularis]

Simplified the if/else block to a ternary as suggested by the reviewer. Both paths still call derive(parentRequest), just with the request constructed differently depending on whether it's BUILD_CONSUMER or not.

[gnodet]

The style suggestion from the previous review has been cleanly addressed -- the if/else block is now a ternary, and the logic is equivalent.

The fix remains correct: readParentLocally() now uses CONSUMER_PARENT when the request type is BUILD_CONSUMER, matching the behavior of resolveAndReadParentExternally(). The conditional (only for BUILD_CONSUMER) is appropriate since BUILD_PROJECT and BUILD_EFFECTIVE already get profile activation via isBuildRequestWithActivation().

The test is thorough -- it sets up the reactor via BUILD_PROJECT, then does a BUILD_CONSUMER build on the child, verifying both property resolution and managed dependency version interpolation.

Note: the dependency on #11768 is still open. This should merge after it.

Claude Code on behalf of Guillaume Nodet