Play Framework

test(launcher): run the bundle launcher tests on Windows through Git Bash (PF-183)

BundleLauncherTest was switched off on Windows, where a shebang script
cannot be executed directly, and reached the launcher's MSYS branch only
by stubbing uname and cygpath on macOS and Linux. The launcher has since
been largely rewritten (certs/.env, JVM options, application.conf keys),
and Windows installs start a bundle through exactly that script under
Git Bash, so a fault that only shows there would first appear as
installs that no longer boot.

On Windows the class now runs the script through Git Bash's own
bash.exe, located the way an installer does (Git\bin\bash.exe, not the
`bash` on PATH, which is WSL's launcher). uname, cygpath and bash are
then the real ones. On CI a missing Git Bash fails the class rather than
skipping it. The one test that asserts the non-Windows branch is
disabled there, and a Windows-only twin asserts that the translated
paths are the directory the bundle is really in.

A new test, on every OS, lets the launcher start a real JVM against a
jar whose play.server.Server reports what it was given: the bundle's
paths, that conf/ is on the classpath, the flags from jvm.memory and
from the command line, and the certs/.env entries. The stub-java tests
cannot see a mistake at the bash-to-JVM boundary; with the wrong
classpath separator this test fails with "conf is not on the classpath"
while the JVM still starts.

Two things only Windows could show. The tests set the child's PATH
under the name the variable already has: there it is `Path`, and
ProcessBuilder's map is case-sensitive on Windows, so putting "PATH"
handed Git Bash both and it kept the original. And a native JVM ends
its lines with CRLF, which the real-JVM test now allows for.

Run on windows-latest (Git Bash, bash 5.3.15, MINGW64_NT-10.0): 27
tests, 26 passed, the non-Windows one skipped.

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