Play Framework

feat(gradle-plugin): AOT cache for a precompiled start from the working copy (PF-185)

An application started through Gradle with -Dprecompiled=true, from its
working copy or from a dist install, could not use the JDK's AOT cache a
bundle has had since PF-180. Its classpath began with three directories
(conf/ and Gradle's build/classes/java/main and build/resources/main), and
the JVM refuses to write a cache while a non-empty directory is on it.

- playRun, playStart and playRestart put only files on the classpath when
  the JVM arguments say -Dprecompiled=true (the last one wins, as in the
  JVM). A start that compiles keeps the directories, which javassist reads
  (PF-94).
- New task playAotGen, `play aot-gen` in the shim: the bundle's training
  run on top of spawnPlay. It writes app.aot in the application directory,
  never precompiles, never touches the pid file, keeps a cache only when
  the JVM finished assembling it, and refuses on Windows.
- A precompiled start passes -XX:AOTCache when app.aot exists, ahead of
  the conf and command-line options, and leaves it out next to an option
  the JVM refuses to start with beside it. The rule is aot_cache_arg of
  bundle-play.sh written a second time; BundleLauncherTest compares the two.
- playDist and playBundle never package app.aot. The skeleton's .gitignore
  names it, and playAotGen says so when git would list it.

Measured as the "Started in" line, medians of five starts on JDK 25.0.2: a
generated application 1,419 ms to 501 ms; jclaw from a scratch working copy
with its production options (ZGC) about 3.7 s to 2.3 s. The change of
classpath alone made no measurable difference.

Behaviour change: a precompiled Gradle start no longer has conf/ or
Gradle's compile output on the JVM classpath, as a bundle has not since
PF-180. The upgrade note is in documentation/manual/deployment.textile.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KDUoh3KhBpfjXn4rV6H356