Play Framework

feat(logging): bridge java.util.logging into log4j2 (PF-175)

The framework routed SLF4J into log4j2 but not java.util.logging, so any
dependency logging through JUL (Lucene's VectorizationProvider, the
OpenTelemetry SDK's export failures) wrote to stderr and never reached the
application's appenders. Under `play start` that meant logs/system.out,
which is truncated on every boot.

log4j-jul 2.26.1 now ships in framework/lib, pinned beside log4j-core
(log4j rejects a mismatched pair at runtime; Renovate already groups
org.apache.logging.log4j). Every Play JVM sets
-Djava.util.logging.manager=org.apache.logging.log4j.jul.LogManager:
registerPlayJvmTask (playRun/playTest/playPrecompile/playEvolutions),
spawnPlay (playStart/playRestart), playAutotest's server JVM and
bundle-play.sh. The ticket named three of those sites; registerPlayJvmTask
is the fourth and covers dev mode.

Each site puts the flag ahead of conf and command-line args so an app's own
value wins under the JVM's last-wins -D. registerPlayJvmTask sets it as a
systemProperty rather than a jvmArgs -D: Gradle emits system properties
before jvmArgs, so a -D there would have beaten an app's
systemProperty(...).

JulBridgeArgsTest drives playRun, playStart and playAutotest against a
fake framework whose Server prints the property the JVM resolved, covering
both the default and the jvm.memory and build-script overrides. Breaking
each site in turn fails exactly its case. BundleLauncherTest covers the
bundle launcher's argv, and JulBridgeTest runs the shipped jars in a child
JVM to check that JUL records reach log4j2 appenders under their own
logger names.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>