Support owner-aware toolchain requirements for multiple Maven reactors

[1lck]

Context

PR #274 makes Java run configurations resolve Maven ownership per source entry. This correctly keeps independent nested reactors on separate cwd and module selectors. Toolchain requirements are still generated from one workspace-level Maven root, however, so configuration ownership and requirement ownership can disagree.

This is broader than #272, which is about recognizing and launching a Java entry point from a nested Maven reactor, and should be handled as a separate follow-up.

Problem

Given one opened workspace containing:

services/alpha/pom.xml  # requires Java 17
services/beta/pom.xml   # requires Java 21

Core can generate an alpha configuration owned by services/alpha and a beta configuration owned by services/beta. If requirement detection selects alpha as the single Maven root, .lithe/toolchains/requirements.json may still declare project-jdk.minimumVersion = 17. Beta then binds the same project-jdk and can be launched with an incompatible JDK.

The same mismatch applies to vendor preferences and Maven wrapper/version metadata: a workspace-level value must not silently describe only one reactor.

Recommended design

Treat Maven owner roots as an explicit input to requirement generation instead of rediscovering one global root.

1. Aggregate constraints that are safely compatible at workspace scope.
   • Set the shared project-jdk.minimumVersion to the highest minimum required by any owned reactor.
   • Keep deterministic ordering so request path order cannot change the result.
   • Preserve existing single-reactor output.
2. Do not publish a false global constraint when values cannot be merged.
   • Emit preferredVendor only when reactor declarations are compatible; otherwise omit it and surface an actionable diagnostic if needed.
   • Resolve Maven wrappers from each launch plan's reactor cwd, as both platform adapters already do.
   • Emit global Maven wrapper/version metadata only when every relevant reactor can be represented by the same reactor-relative value.
3. Introduce reactor-scoped toolchain identities only for genuinely incompatible requirements.
   • If the product must support different mandatory JDK vendors or versions per reactor, extend the shared schema and configuration bindings with stable workspace-relative reactor ownership.
   • Update Rust Core, macOS, Windows, shared contracts, persistence migration, diagnostics, and toolchain-selection UX together rather than encoding reactor paths ad hoc in one platform.

The first two steps should solve the Java 17/21 case without multiplying toolchain IDs. The third step should remain conditional on a real requirement that one shared compatible JDK cannot satisfy.

Acceptance criteria

• A regression fixture with alpha requiring Java 17 and beta requiring Java 21 produces a deterministic Java 21 workspace minimum regardless of request order.
• Conflicting vendor declarations do not become a misleading workspace-level preference.
• Different reactor-local Maven wrappers are selected from each configuration's cwd; incompatible wrapper versions are not collapsed into one global version.
• A single-reactor project keeps its current requirement document and launch behavior.
• Standalone Java entries in a mixed workspace remain JDK-backed and do not acquire Maven requirements.
• Shared contract documentation and fixtures describe aggregation and conflict behavior.
• Rust Core focused/full verification and Windows/macOS boundary tests pass.

Related

• Windows fails to run Java entry points in nested Maven reactors #272
• fix(maven): detect nested reactors from Java paths #274