Separate sample projects from test infrastructure

[adinauer]

Currently our samples double as integration tests, which causes buildscript classpath bleed between the main build and the sample projects. This creates two categories of problems:

Isolation failures observed

• A test matrix leg targeting a specific KGP version was silently resolved to a higher version because another build dependency pulled it in transitively
• Sample dependency constraints (e.g. an older Spring Boot requiring a pinned KGP version) block upgrades to the rest of the build

Goals

• Samples should use only published Maven Central coordinates so customers can copy them verbatim — no project references, no snapshots
• Integration tests should live in a separate Gradle project (or composite build) with an isolated buildscript classpath, publishing to a build-local directory for resolution
• Changes to the main build graph should not be able to silently alter what the samples or integration tests resolve

Proposed direction

• Extract sample apps into standalone Gradle projects (or an isolated composite build) that declare no project(...) dependencies
• Run integration/system tests against those standalone projects, resolving SDK artifacts from a build-local Maven directory (see Use build-local dir instead of project deps in samples #5711)
• CI wires the publish-to-local-dir step before the sample test step, keeping full per-PR coverage

Out of scope

• The build-local dir plumbing itself (tracked in Use build-local dir instead of project deps in samples #5711)
• Publishing samples to any external registry

--

View Junior Session in Sentry

[linear-code]

JAVA-626