Play Framework

fix: include Gradle-resolved runtimeClasspath in playClasspathFor (PF-90)

Surfaced during Phase 7 app migration: payments and api both have
build.gradle.kts dependency declarations that weren't actually reaching
playRun's classpath. The plugin's playClasspathFor() was building a
classpath from conf/, framework jar, app's lib/, modules' lib/, and
framework's lib/ -- but NOT from the consumer's Gradle-resolved deps
(implementation, etc.).

This worked accidentally for jclaw because jclaw's lib/ already had
all the right jars from prior `play deps` runs, so the classes were
on the classpath via the lib/ path even though Gradle resolution was
ignored. payments showed the bug clearly: lib/ had 1.11.0-era netty
that crashes under JDK 25, and the new Gradle-declared netty 4.2.x
never got loaded.

Fix: add sourceSets.main.runtimeClasspath to the FileCollection
passed to JavaExec/ProcessBuilder. Placed BEFORE app's lib/ in the
ordering so Gradle-resolved versions win when both are present (lib/
is kept for backward compat with manually-placed jars).

Migration note for users: clear out stale lib/ before first
gradle playRun -- play deps under the python CLI populated lib/
with version-pinned jars that may now conflict with what Gradle
resolves. lib/ is gitignored in all play apps' default
.gitignore, so safe to rm -rf lib/*.