[#12288] Backport: settings.xml activeByDefault profile props to LRM

[ascheman]

@gnodet — for review (you endorsed this backport in #12288).

Backport of #12297 (merged on master, also backported to maven-4.0.x
via #12299) to the maven-3.10.x maintenance line:

A backport to maven-3.10.x (targeting 3.10.0 / 3.9.17) should be
straightforward — the same DefaultRepositorySystemSessionFactory. getPropertiesFromRequestedProfiles method exists on the 3.x branch.
The activeByDefault property-propagation gap and the missing
deactivation check (-P !id) apply there identically.

What changes (on 3.x)

Adapted minimal-diff (4 net lines added to
DefaultRepositorySystemSessionFactory#getPropertiesFromRequestedProfiles):

• Adds the <activation><activeByDefault>true</activeByDefault> branch to
  the profile filter — this is the actual gap on 3.x.
• Adds the -P !id deactivation guard (per the review hardening on
  master, 57852351).

On 3.x, request.getActiveProfiles() already returns CLI -P + settings.xml
<activeProfiles>, so the master fix's additional propagation of those
channels is not needed on this line. Only <activeByDefault> was
broken on 3.10.x.

Why not a verbatim cherry-pick

Path and API divergence between master and 3.10.x prevented a clean
cherry-pick -x:

• Path: master has impl/maven-core/src/main/java/...; 3.x has
  maven-core/src/main/java/....
• API: master uses
  request.getProfileActivation().get{Required,Optional}{Active,Inactive}ProfileIds();
  3.x uses request.getActiveProfiles() / getInactiveProfiles() returning
  List<String>.

The commit body explicitly cites the master origin commits
(3e2c7560 and 57852351) for traceability.

Tests

Integration tests for #12288 on the 3.x line live in
apache/maven-integration-testing
and are addressed by a parallel PR there (will reference here once open).
The IT coverage includes:

• testActiveByDefaultProfile (master 7725eaf2)
• testActiveProfilesList (master 7725eaf2, baseline regression guard)
• testActiveByDefaultDeactivatedViaCli (master [#12288] Add -P !profile deactivation regression guard #12298, regression guard for
  the -P !id deactivation that is also in this PR)

Locally: mvn -pl maven-core -am clean install — green.

References #12288, #12297, #12298, #12299.

[gnodet]

Clean, minimal, well-documented backport. CI is fully green (18/18).

Correctness

The filter predicate is structurally identical to the master fix (#12297):

activeIds.contains(id) || (!inactiveIds.contains(id) && activation != null && isActiveByDefault())

The API adaptation from ProfileActivation.getRequired/OptionalActive/InactiveProfileIds() (master) to request.getActiveProfiles()/getInactiveProfiles() (3.x) is correct — on 3.x, getActiveProfiles() already returns the union of CLI -P and settings.xml <activeProfiles> (confirmed in DefaultMavenExecutionRequestPopulator), so the separate channel propagation from master is not needed.

Null safety (profile.getActivation() != null), deactivation guard (!inactiveProfileId.contains(...)), and property override safety (this method's output is overridden by system/user properties downstream) all check out.

Minor observations (non-blocking)

1. The master fix added .filter(e -> e.getValue() != null) before collect(). This backport omits it, but this is consistent with pre-existing 3.x code, and Properties (from ModelBase.getProperties()) cannot contain null values by Hashtable contract — harmless.

2. Worth linking the companion apache/maven-integration-testing PR here once it's open, for traceability.

Fully automatic review from Claude Code. This review does not replace specialized AI review tools or static analysis.