Preserve Wright lint and analyze semantics across the OPY provider boundary

[Teakowa]

Parent: #242
Depends on: #243, wrightkit/opy-rs#170

Goal

Keep wright lint and wright analyze as Wright-owned canonical Workshop tooling while running real OverPy projects through the first-party OPY provider, with truthful attribution back to original OPY source where the approved provider/provenance contract supports it.

Context

Provider-backed check / compile can operate directly on owner diagnostics and a Workshop artifact. lint / analyze have a different integration requirement: Wright must consume canonical Workshop semantic evidence without moving its rules/reporting into opy-rs, while avoiding fabricated source locations or exposure of provider-internal AST/HIR/WIR.

This issue is the product proof that providerization does not reduce Wright-owned tooling to generated-Workshop-only output.

Scope

• Route real OPY projects through the approved provider/source boundary and obtain the canonical semantic input required by the existing Wright lint/analyze implementation.
• Keep lint rules, evidence classification, ranking/reporting, and analyze behavior in Wright.
• Preserve or map original OPY source identity/provenance according to the approved cross-boundary contract.
• Represent unmappable/generated-only evidence explicitly rather than assigning false OPY locations.
• Reuse the same Wright analyzer/lint implementation used for raw Workshop wherever the canonical semantic contract is shared.
• Preserve structured owner diagnostics alongside Wright findings/report output.
• Verify bounded, useful output on pinned Bastion and Overwatch-AI-PVE revisions rather than treating exhaustive semantic dumps as success.
• If the current LPP v1 contract is proven insufficient for the required handoff, stop and create the smallest owning protocol issue with concrete real-project evidence before adding an ad hoc Wright/provider workaround.

Non-goals

• Implementing Wright lint rules or analyze reports inside opy-rs.
• Exposing OPY AST/HIR/compiler internals or Wright/workshop-rs internal representations over the wire solely for convenience.
• Adding new lint rules, heuristics, or performance claims as part of this integration task.
• Regenerating OPY source or adding semantic edits/refactoring.
• Treating generated Workshop line numbers as original OPY provenance when no valid mapping exists.
• Redesigning LPP speculatively without a demonstrated workflow gap.
• Migrating real-project CI before Make Wright CLI CI-ready for real Workshop and OverPy projects #242 final verification.

Acceptance criteria

• wright lint runs on the pinned Bastion and Overwatch-AI-PVE project revisions through the provider-backed OPY path and uses Wright's existing lint registry/rules rather than provider-owned copies.
• wright analyze runs on the same revisions through the provider-backed OPY path and produces the existing bounded semantic report from canonical semantic evidence.
• Owner diagnostics and Wright findings remain distinct in the result model and preserve their respective provenance.
• Findings/report evidence that maps to original OPY source uses valid original source identities/ranges supplied or derived through the approved contract.
• Evidence that cannot be mapped to original OPY source is explicitly identified as unmapped/generated/canonical evidence rather than assigned a fabricated source location.
• Raw Workshop lint/analyze continue to use the same canonical Wright analyzer/lint behavior and remain regression-green.
• No OPY language semantics, project loading, or lint-rule implementation is duplicated in Wright.
• Any required protocol change is backed by a minimized and provenance-linked real-project failure showing why the current contract cannot satisfy the workflow.
• Text/JSON/CI renderers remain deterministic and bounded for the real projects.
• Independent verification reruns both real projects after implementation.
• Implementation ablation that removes the canonical/provenance handoff causes the relevant real-project lint/analyze evidence to fail or lose the expected mapping, proving the integration is exercised.

Dependencies / ownership

• Parent: Make Wright CLI CI-ready for real Workshop and OverPy projects #242.
• Converge source-language workflows on an explicit provider boundary #243 owns the product-facing provider/source/diagnostic boundary and its approved provenance/canonical-semantic handoff.
• wrightkit/opy-rs#170 owns the first-party OPY provider and owner-side project/source behavior.
• Run real OPY check and compile workflows through the first-party provider #245 establishes the first real provider-backed OPY check/compile workflow and may provide reusable integration evidence, but this issue has an independent provenance/tooling failure mode.
• language-provider-protocol owns any required wire-contract change if a concrete gap is demonstrated.
• workshop-rs remains the canonical Workshop semantic owner.

Readiness

Blocked until #243 and the relevant provider/provenance design are approved. Do not solve missing provenance by adding Wright-side OPY semantics or provider-private wire fields.

[Teakowa]

Current reality update (2026-09-03): #246 remains downstream of the production provider cutover in #245.

Wright's current SourceProvider seam can hand canonical Workshop text into Wright-owned lint/analyze, but the canonical-artifact provenance state is currently only Unmapped. Existing seam tests intentionally report findings against <provider-artifact> rather than pretending those Workshop spans are authored OPY spans.

After #245 is real, run pinned Bastion and Overwatch-AI-PVE wright lint / wright analyze over the provider-produced canonical Workshop evidence and evaluate the actual diagnostic/query usefulness. Do not fabricate OPY source mapping in Wright. If the real workflow demonstrates that authored-source mapping is required for the milestone, define the smallest owner/protocol provenance contract first; otherwise keep the explicit unmapped/generated evidence for this stage.

Keep #246 open and avoid speculative provenance abstractions before the provider-backed check/compile path is operational.