Windows fails to run Java entry points in nested Maven reactors

[1lck]

Problem

When a workspace contains a Maven reactor below the opened root, Windows run-configuration discovery may submit only Java source paths to Rust Core. Maven discovery currently recognizes nested reactors only when a pom.xml path is included, so the Java entry point is misclassified as a plain java.main configuration and launched directly through the JDK. The project then cannot run with its Maven module classpath.

This is a follow-up regression scenario to #26: nested Maven roots are supported when build descriptors are visible, but not when the platform request contains only Java paths.

Expected behavior

• Maven discovery checks the ancestor directories of supplied Java paths for pom.xml.
• Generated Java entry points inside a Maven module bind to project-maven and launch from the reactor root.
• Persisted plain-Java configurations generated by the old detector are invalidated or rejected with an actionable regeneration message.
• The shared Rust Core behavior remains consistent on macOS and Windows.

Scope

This issue covers Maven reactor/module recognition and stale run-configuration handling. Maven settings.xml, profiles, custom local repositories, and private repository credentials are separate follow-up work.

Acceptance criteria

• A nested reactor is detected when runConfig.generate receives only a workspace-relative Java source path.
• The generated launch plan uses the Maven toolchain and correct module selector.
• Old misclassified java.main plans cannot silently launch with an incomplete classpath.
• Shared contract fixtures and cross-platform regression tests cover the behavior.

[1lck]

Resolved by #274 and merged into preview in commit 0ef9e6fb5572143bd7c41f0f7991e40384ed792a.