Revert to released Maven Central JARs once a gtfs-modules release includes PR #471

[aaronbrethorst]

What

Once an onebusaway-gtfs-modules release ships that contains OneBusAway/onebusaway-gtfs-modules#471 (the --duplicateRenaming merge-cli flag), remove the build-from-source Maven stage added by #2 and return the Dockerfile to pinning released artifacts:

• Delete the jars builder stage and the GTFS_MODULES_REF ARG.
• Restore the two Maven Central curl layers with JAR_VERSION set to the new release (expected 14.0.1 or later — verify the release notes actually include PR #471 before bumping; a release cut from main without that PR merged would silently reintroduce the missing flag).
• Rebuild and rerun the build-tagged integration suite against the released JARs (GTFS_MERGE_CLI_JAR env var).
• One staging dry run + verification report on a real combined feed, same as the builder-stage rollout, to confirm the released JAR behaves identically to the SHA we were building.

Why bother reverting

The builder stage is a stopgap: it makes image builds slower (full Maven compile), pins us to a moving upstream branch by SHA, and duplicates what a release artifact provides. Released, checksummed JARs from Maven Central are the steady state.

Watch

Upstream releases: https://github.com/OneBusAway/onebusaway-gtfs-modules/releases — the trigger is the first release whose changelog includes PR #471.