[Naenyn]

Problem

CI runs a bare mvn -B package, so it uses whatever Maven the GitHub runner image ships — a version that drifts over time. A recent runner Maven bump has been breaking builds across the uPortal portlets. 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).

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#448 and CalendarPortlet#429; these portlets share the same CI shape and Java 11 constraint. Part of a fleet-wide pass to insulate CI from runner Maven drift.

[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. The policy could be centralized though — a requireMavenVersion enforcer rule (e.g. [3.9,4.0)) in uportal-portlet-parent would make every descendant fail fast 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.