feat(provider): ship first-party LPP provider

[e54-bot]

Summary

• ship the first-party LPP 1.1 provider with entry-based project loading and versioned source diagnostics
• return the complete loaded source closure from lpp/compile, including clean files, with regression coverage for a clean multi-file project
• close the demonstrated OPY parser, preprocessing, lowering, settings, and catalog-surface gaps needed by the pinned Bastion and OW1 workflows

Review follow-up

• lpp/compile now returns every loaded source document rather than only documents containing diagnostics; the clean five-file project fixture verifies this contract.
• The OPY-to-canonical mapping for setEnvironmentalKillCreditor now resolves to the catalog-backed setEnvironmentCreditPlayer action from the pinned workshop-rs 0.1.16 catalog. The additional real-project member/value links exposed by the same pinned OW1 gate are catalog-backed as well.
• Parser source spans now end at the parsed expression/argument rather than the next token, preserving valid provenance across #!include file boundaries.
• Scalar Player iterables in comprehensions are wrapped as singleton Array values before canonical filteredArray lowering; a regression test proves the emitted WIR argument type.
• heroes.<team>.general settings are flattened to the canonical team scope, with a regression test covering the real-project settings shape.
• Bastion completes the entry initialize(1.1), check, and compile protocol sequence with 170 loaded documents, zero diagnostics, and a non-empty artifact.
• The current OW1 project completes entry-based initialize(1.1) and lpp/compile with its full 313-document closure, zero diagnostics, and a non-empty artifact after the scalar-array and team-general fixes.
• The historical pinned OW1 fixture remains an explicit opy-rs#47 known gap at its legacy append integration frontier; this is kept separate from the current real-project provider result.

Verification

• cargo fmt --all -- --check
• cargo clippy --workspace --all-targets --all-features -- -D warnings
• cargo test --workspace --all-targets --all-features — passed (299 opy-rs tests plus provider/CLI targets)
• python3 -B -m unittest discover -s compatibility/tests — 35 passed
• python3 -B compatibility/run_native.py --binary target/debug/opy-cli --semantic-binary target/debug/opy-compat --results target/opy-rs-compiler-results --report target/opy-rs-compiler-report.json — 63 fixtures; 63 compile-status matches
• python3 -B compatibility/conformance.py --binary target/debug/opy-cli --semantic-binary target/debug/opy-compat --report target/opy-rs-conformance-report.json — report generated; current divergences/inconclusive cases remain visible by design
• actionlint .github/workflows/provider-release.yml
• cargo package --locked -p opy-provider --allow-dirty
• independent ablation: removing the scalar-player normalization makes the regression test fail at canonical WIR compilation
• live OW1 provider probe: entry initialize(1.1) and lpp/compile; 313 loaded files, zero diagnostics, artifact returned

The provider consumes the owner-published entry contract from language-provider-protocol#16 and does not add a private protocol shape.

Fixes #170

[Teakowa]

Major — crates/opy-provider/src/main.rs (PROTOCOL_VERSION, Capabilities::as_json, ProjectParams / load_project) plus the provider tests/docs implement project loading as 1.0 + entryUri. The published owner contract makes entry-based loading an LPP 1.1 extension: negotiate 1.1, advertise projectLoading: true, accept entry: { uri, languageId, version }, echo the entry version for every filesystem-loaded result, and use the specified invalidEntry / projectLoadFailed errors. The current private shape cannot be consumed as the contract required by #170. Update the adapter, tests, and docs to the published LPP 1.1 contract; retain 1.0 only if that path is fully conformant.

Major — load_project does not satisfy the document-supplied lpp/check contract that the provider advertises. A request with more than one documents entry is refused unless an entry is supplied, and non-entry document text is not used by the owner frontend for included files. LPP requires check to analyze every supplied document from that request snapshot. Implement the canonical document-supplied path, or otherwise stop advertising a protocol/capability combination that requires it.

Major — #170 requires pinned Bastion and Overwatch-AI-PVE provider check and compile workflows to be independently rerun, plus an implementation ablation. The PR currently names no pinned revisions or reproducible check/compile results for both projects, and the PR CI does not exercise those real-project workflows. Record the exact revisions and independent commands/results (including both check and compile) and the ablation outcome so this acceptance evidence is verifiable.

[Teakowa]

Major — the LPP 1.1 project-loading fix is still incomplete for lpp/compile. compile_diagnostics() builds result entries only from diagnostic-bearing paths (or just the main file when there are no diagnostics), so a multi-file entry compile omits clean loaded source files. The published LPP 1.1 contract requires entry-based check and compile results to include diagnostics entries for every loaded source document, including clean files, all using the entry version. Return the full loaded source closure for compile as well and add contract coverage for a clean multi-file compile.

Major — the pinned-project evidence is now recorded, but it demonstrates that #170's real workflow still does not work: Bastion returns 72 diagnostics and artifact: null, and Overwatch-AI-PVE returns 125 diagnostics and artifact: null. #170 requires blockers demonstrated to belong to OPY source semantics/compiler lowering to be fixed in opy-rs (or canonical Workshop blockers reassigned to workshop-rs) before this provider closes the real-project workflow. Classify/fix or reassign those blockers and rerun the pinned check/compile probes; both target projects currently failing compilation is not completion evidence.

[Teakowa]

Major — current head CI is red in Compiler compatibility gate: real-world/ow1-emulator is reported as a diagnostic-code regression by the native compatibility gate. This was introduced by the new owner-semantics fixes in this follow-up, so resolve the regression (without weakening the existing compatibility expectation) before merge.

Major — OW1 is now reduced to setEnvironmentalKillCreditor, and the PR classifies it as a canonical workshop-rs catalog blocker, but I cannot find a corresponding owning workshop-rs Issue/PR. #170 explicitly requires canonical Workshop blockers to be reassigned rather than bypassed. Create/link the owning workshop-rs blocker and make the dependency/closure state explicit; the provider does not need to fake support for it.

Superseded: this review incorrectly attributed setEnvironmentalKillCreditor to a missing workshop-rs catalog action and treated the resulting diagnostic-code baseline change as a conventional regression. Replacing it with the corrected owner-level finding.

[Teakowa]

Major — setEnvironmentalKillCreditor is not a missing canonical Workshop action. workshop-rs 0.1.16 already catalogs Set Environment Credit Player as setEnvironmentCreditPlayer, and upstream OverPy maps .setEnvironmentalKillCreditor to that Workshop action. The remaining OW1 unknown-member is therefore an opy-rs member/catalog-link defect, not a workshop-rs ownership blocker. Add the correct OPY→canonical mapping and rerun the pinned OW1 check/compile evidence. The current diagnostic-code CI failure is the old parse-error baseline being invalidated by progress past that parser gap; refresh that expectation only from the independently verified post-fix result, rather than accepting the current unknown-member as a new known gap.

[Teakowa]

Major — the setEnvironmentalKillCreditor mapping is fixed, but the rerun now demonstrates a new opy-rs compiler/WIR blocker: OW1 check is clean, while compile still fails with unsupported-integration-surface for multiple switch breaks and emits no artifact. #170 requires demonstrated OPY compiler/lowering blockers to be fixed in opy-rs for this real-project workflow; reclassifying the fixture as a known gap and assigning it to completed #47 does not satisfy that acceptance criterion. Resolve the switch/WIR limitation (or, if evidence shows different ownership, reclassify it accordingly), then rerun the pinned OW1 provider compile and refresh the compatibility expectation from that result.

[Teakowa]

Major — #173 resolves the previous multiple-switch-break blocker, but its pinned OW1 rerun on this stacked code now advances to another opy-rs compile blocker: catalog-validation reports filteredArray expects Array, got Player, and no artifact is produced. The pinned source uses the valid getLivingPlayers(...).filter(lambda ...) form; canonical Workshop data declares getLivingPlayers as returning Array and filteredArray as accepting Array, so the invalid type reaching WIR validation is an OPY lowering/array-callback defect, not a canonical Workshop blocker. #170 requires demonstrated OPY compiler/lowering blockers to be fixed before this real-project provider workflow is complete. Fix this owner-level lowering/type-propagation gap and rerun the pinned OW1 lpp/compile evidence; completion still requires the real workflow to get past owner blockers rather than merely reaching the next one.

[Teakowa]

LGTM