fix: propagate addResource() to model Build for Maven 3 compat

[gnodet]

Summary

• When a Maven 3 plugin dynamically adds a resource via project.addResource() or project.getResources().add(), propagate the change to the model's Build.resources so that project.getBuild().getResources() stays in sync with project.getResources()
• After project building, sync Build.resources/Build.testResources from the sources set so that resources defined via <sources> (Maven 4.1.0) are also visible through project.getBuild().getResources()
• This fixes resource ordering issues when running Maven 3 plugins (e.g. maven-source-plugin 3.x) on Maven 4

Root cause

In Maven 3, project.getResources() and project.getBuild().getResources() return the same mutable list. In Maven 4's compatibility layer, they are disconnected: getResources() returns a virtual list backed by the internal sources set, while getBuild().getResources() returns a WrapperList backed by the model.

When maven-remote-resources-plugin adds a resource directory, only the sources set was updated. The maven-source-plugin's createArchiver() method uses project.getBuild().getResources() to find the maven-shared-archive-resources directory and add META-INF files first in the JAR — but in Maven 4 it couldn't find it, causing the META-INF entries to appear at the end instead of the beginning.

Additionally, when resources are defined via <sources> (Maven 4.1.0 model), they were only added to the sources set but not reflected in Build.resources, making them invisible to Maven 3 plugins accessing resources via project.getBuild().getResources().

See: apache/maven-source-plugin#281

Test plan

• Existing ResourceIncludeTest passes (10 tests)
• Full maven-core test suite passes (545 tests)
• Verify with maven-source-plugin 3.x reproducible IT on Maven 4

🤖 Generated with Claude Code