[Naenyn]

Problem

CI runs a bare mvn -B package, so it uses whatever Maven the GitHub runner image ships. That version drifts over time, and a recent runner Maven bump started failing builds on long-standing POM constructs (notably this repo's duplicate maven-antrun-plugin declaration, which older Maven tolerated as a warning).

Maven 4 is not a viable target here: it requires Java 17 to run, while this portlet targets Java 11.

Change

• Add the Maven Wrapper pinned to 3.9.16 (latest Java-11-compatible line): mvnw, mvnw.cmd, .mvn/wrapper/maven-wrapper.properties.
• Switch CI from mvn -B package to ./mvnw -B package.
• Add a repo .gitignore negation so .mvn/wrapper/maven-wrapper.properties is tracked (a global ~/.gitignore commonly ignores .mvn).

This pins the build to a fixed, reproducible Maven regardless of the runner default, and keeps it on the Java 11 line.

Verification

./mvnw -v → Apache Maven 3.9.16 on Java 11.
./mvnw -B package → BUILD SUCCESS locally on Java 11.

Notes

• Same change as NewsReaderPortlet (build(ci): pin Maven to 3.9.16 via the Maven Wrapper NewsReaderPortlet#448); these portlets share the same CI shape and Java 11 constraint.
• This repo also carries a latent duplicate maven-antrun-plugin declaration (a warning on Maven 3.9, a hard error on newer Maven). Pinning to 3.9.16 keeps CI green now; the duplicate can be cleaned up separately.

[Naenyn]

Follow-up idea (not for this PR): the wrapper pins the Maven binary per-repo, which is necessarily per-repo since the Maven version is selected before any parent POM is read (and the workflow lives here, not in the parent artifact). But the policy could be centralized: a requireMavenVersion enforcer rule (e.g. [3.9,4.0)) in uportal-portlet-parent would make every descendant fail fast with a clear message on an unsupported Maven (notably Maven 4, which needs Java 17). The parent already uses the enforcer plugin, so it'd slot in naturally and backstop the per-repo wrappers once portlets consume the updated parent.