Allow provider-owned project loading from an entry target

[Teakowa]

Goal

Allow an LPP provider to own source-language project discovery from a client-selected entry target, so clients such as Wright do not need to duplicate language-specific project loading merely to construct a complete DocumentSet.

Context

The current LPP v1 document model requires the client to provide every document a request may need and requires providers not to assume additional documents exist outside that set.

That contract conflicts with the real OPY integration required by wrightkit/wright#242 and wrightkit/wright#243: opy-rs owns #!mainFile, #!include, preprocessing/macros, and project/source closure, while Wright should only resolve the user-selected CLI path and delegate project loading to the language owner.

Making Wright recursively collect OPY files would create a second OPY project loader and violate the approved ownership boundary.

Scope

• Add the smallest LPP request contract needed for a provider to load a filesystem-backed project from a client-selected entry URI/path.
• Preserve the existing process/session model and structured diagnostics.
• Define the filesystem/project-loading authority sufficiently for the first-party OPY provider used by Wright.
• Keep source identities in provider results stable and suitable for diagnostics/provenance.
• Validate the contract with the OPY provider workflow from wrightkit/opy-rs#170 and Wright integration from wrightkit/wright#243.

Non-goals

• General workspace synchronization.
• Unsaved editor overlays or LSP document-state synchronization.
• A package/project dependency model.
• Language-specific project discovery rules in LPP.
• OPY-specific semantics in the protocol.
• Redesigning LPP transport, process lifecycle, or provider distribution.
• Exposing provider AST/HIR/WIR.

Acceptance criteria

• A client can identify an OPY entry target without preloading the complete OPY source closure into a DocumentSet.
• The provider can load additional project files according to the source-language owner's rules.
• Wright does not need to scan OPY files, interpret #!mainFile, resolve #!include, or infer an OPY project root.
• Existing source diagnostics retain stable source identity across the process boundary.
• The extension is language-neutral and no broader than required by the pinned real OPY workflow.
• Existing document-supplied workflows remain compatible unless an explicit versioned contract change is required.
• Independent design ablation shows that removing the entry/project-loading capability forces the real OPY workflow back into client-side project discovery or makes it impossible.

Dependencies / ownership

• language-provider-protocol: owns this process/wire contract.
• wrightkit/wright#243: owns Wright's entry-based product/provider boundary.
• wrightkit/opy-rs#170: owns OPY project discovery and the first provider implementation exercising this contract.
• wrightkit/wright#242: real-project product milestone providing the validation workflow.

Readiness

Ready. The missing contract is demonstrated by the current LPP DocumentSet requirement and the approved OPY ownership boundary; no additional product or architecture decision is required.