fix(maven): detect nested reactors from Java paths

[1lck]

Closes #272

Summary

• discover nested Maven reactors by walking ancestor directories of supplied Java source paths
• resolve Maven ownership per Java entry, preserving standalone JDK launches and independent nested reactors in mixed workspaces
• bind Maven-owned Java entry points to project-maven and reject stale plain-Java launch plans
• version the run-configuration generator fingerprint so detector upgrades invalidate persisted generated output
• document the shared behavior and add a mixed-workspace compatibility fixture

Why

Windows run discovery can provide all Java paths in one request. Request-level Maven ownership incorrectly routed standalone sources and entries from other nested reactors through the first selected reactor. The fix lives in shared Rust Core and resolves owner, working directory, module, and Maven toolchain for each Java entry, so macOS and Windows use one deterministic implementation.

Validation

• cargo fmt --manifest-path rust/lithe-core/Cargo.toml -- --check
• cargo test --manifest-path rust/lithe-core/Cargo.toml tests::run_configuration:: -- --nocapture (36 passed on macOS)
• ./scripts/verify-rust-core-comments.sh
• ./scripts/verify-rust-core.sh (242 Rust Core tests passed, plus Swift bridge verification)
• ./scripts/verify-shared-contracts.sh
• ./scripts/verify-windows-boundaries.sh
• Windows Rust Core run-configuration tests through Parallels (36 passed)
• Windows ARM64 Release build through Parallels (aarch64-pc-windows-msvc)
• Windows Tauri Rust tests through Parallels (88 passed)

Out of scope

Maven settings.xml, profiles, custom local repositories, and private repository credentials remain separate follow-up work.

[1lck]

@lithe review

[github-actions]

Lithe Review

结论： ⛔ 存在阻塞问题
依据： Issue #272 · a3a8cb302863d8eb5a9b04524e7611e62f7c3c6e ← be0c6d24ab26ef846bb92c7153dc19c29f5f4752 · head: be0c6d2

变更理解

本次改动从所提交 Java 路径的祖先目录发现嵌套 Maven reactor，并通过生成器指纹和启动前校验淘汰旧的纯 Java 配置。

发现

1. [P1] 不要把同一请求中的非 Maven Java 主类绑定到已发现的嵌套 reactor
   rust/lithe-core/src/project/maven.rs:182

   新增的祖先遍历只要从任意一个路径发现 pom.xml，就会为整个生成请求选出一个 maven_root。调用方随后在 configuration.rs:489 使用全局 has_maven_project，给该请求中所有 java.main 配置添加 project-maven，并在 configuration.rs:513 将其工作目录统一设为该 reactor 根。Windows 的 run.store.ts:272-273 会把 listJavaSources(root) 返回的全部 Java 文件一次性提交，因此可构造工作区同时包含 projects/demo/pom.xml 下的 Maven 应用和 samples/Standalone.java：后者也会被生成成 Maven 配置，模块默认为 .，最终从 projects/demo 执行 exec-maven-plugin，因该 reactor 不包含该类而启动失败。这是路径仅含 Java 文件时由本 PR 新触发的回归。应按每个主类的源路径判断其是否属于选中的 reactor（并据此分别设置 toolchain、cwd 和 module），而不是用请求级布尔值绑定全部 Java 配置。

验证

• 检查了 5 个变更文件，并追踪了 Maven 根选择、Java 模块归属、生成/解析/启动计划、macOS 与 Windows 请求调用方、相关 Rust 测试及共享契约 fixture
• 已提供的 CI 状态：Database CI gate、Plugin CI gate 和变更分类成功；Rust Core/Swift bridge、Release、Swift、Windows 实现检查仍在进行；数据库与插件测试已跳过
• 本次审查未运行测试

[1lck]

Addressed the blocking review findings in 8aa99254:

• Maven ownership is now resolved per Java entry rather than per generation request. Mixed Maven/standalone workspaces keep standalone classes on project-jdk, and independent nested reactors retain separate cwd, module, and Maven bindings.
• The generator revision test now computes the real pre-revision fingerprint, so removing the revision salt makes the test fail.
• Added regression coverage for both mixed workspaces and multiple independent nested reactors.
• Merged the latest preview before the fix.

Verified on macOS (36 focused tests; 242 Rust Core tests and Swift bridge) and Windows ARM64 via Parallels (36 focused tests, Release build, 88 Tauri tests).

[1lck]

CI follow-up: all Maven-relevant and platform checks passed, including Windows CI, Rust Core and Swift bridge, and release package verification.

The Swift test lane was rerun once after its first timeout. Both attempts hung at the unrelated tomlIncrementalHighlightingUsesCachedLineStateNearDocumentEnd() test and were terminated by the step fixed 12-minute timeout; no Swift or syntax-highlighting files are changed by this PR. I did not expand this Maven fix to alter the unrelated Swift test or workflow.

[1lck]

The multi-reactor toolchain-requirement mismatch is valid, but it is broader than #272 and the nested-reactor launch fix in this PR. It is now tracked separately in #285 with an owner-aware requirements design, compatibility rules for JDK/vendor/wrapper constraints, and cross-platform acceptance criteria.

PR #274 will not add that toolchain-contract expansion; its scope remains nested Maven discovery and per-entry launch ownership.