Remove residual static OPY implementation after provider cutover

[Teakowa]

Parent: #242
Depends on: #243, #245, #246

Goal

After the provider-backed OPY product path is proven on real projects, remove residual static OPY implementation dependencies, lowering shims, and compatibility fallbacks that would keep Wright coupled to the opy-rs release cadence.

Retain only Wright-owned integration/tooling types and the justified direct canonical workshop-rs dependency.

Context

Wright still carries static OPY integration and build-time source-language dependencies. The product direction in #240/#242 moves first-party OPY delivery to an independently released LPP provider. Keeping a second static OPY path after that cutover would preserve release coupling and create ambiguous fallback/ownership behavior.

This issue is post-cutover cleanup required by that product boundary, not a precondition for proving the provider path.

Scope

• Re-evaluate wright-opy, wright-ir, and direct OPY-related workspace dependencies after Run real OPY check and compile workflows through the first-party provider #245/Preserve Wright lint and analyze semantics across the OPY provider boundary #246 establish the provider-backed real-project path.
• Remove build-time opy-rs / legacy OPY compiler dependencies from the shipped Wright product where they exist solely for source-language implementation behavior now owned by the provider.
• Remove residual Wright-owned OPY HIR/lowering implementation, static source-language adapters, and compatibility fallbacks that are no longer required by a concrete Wright-owned contract.
• Remove Workshop-type/infrastructure re-export shims where Wright can consume canonical workshop-rs contracts directly.
• Retain Wright-owned analyzer/tooling/integration types that have an actual consumer contract and do not duplicate source-language semantics.
• Preserve the raw Workshop path, shared canonical analysis, CLI/machine contracts, and provider-backed OPY workflows.

Non-goals

• Removing Wright's justified direct workshop-rs dependency.
• Changing OPY semantics, lowering, project loading, or compatibility behavior in Wright.
• Redesigning Design lightweight first-party language provider distribution and lazy loading #240/Converge source-language workflows on an explicit provider boundary #243 provider architecture during cleanup.
• Removing a type solely because its historical name contains ir; ownership and active consumers decide the boundary.
• Unrelated crate/workspace refactoring or public API cleanup.
• DEL/OSTW provider cutover in this milestone.

Acceptance criteria

• The shipped Wright product no longer has a build-time dependency on opy-rs, opy-compiler, or another OPY implementation package solely to implement first-party OPY source behavior.
• OPY check, compile, lint, and analyze continue to use the provider-backed path established by Run real OPY check and compile workflows through the first-party provider #245/Preserve Wright lint and analyze semantics across the OPY provider boundary #246, with no silent static fallback.
• Wright contains no authoritative OPY HIR/lowering/project-loading implementation duplicated from opy-rs.
• Any retained wright-ir / integration types have a concrete Wright-owned tooling purpose and do not become a second canonical OPY or Workshop model.
• Direct workshop-rs usage remains only for Wright-owned canonical Workshop/tooling behavior.
• Raw Workshop workflows and existing CLI/machine contracts remain regression-green.
• Removing the static path does not change declared supported semantics; real-project Bastion and Overwatch-AI-PVE provider workflows are rerun after the cleanup.
• Implementation ablation/reintroduction checks demonstrate that the provider path, rather than a remaining static dependency, is what satisfies the real-project OPY workflow.

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 defines the explicit provider/source/canonical-provenance boundary.
• Run real OPY check and compile workflows through the first-party provider #245 proves the provider-backed OPY check/compile workflow on real projects.
• Preserve Wright lint and analyze semantics across the OPY provider boundary #246 proves provider-backed lint/analyze semantics and truthful provenance.
• opy-rs remains the OPY source-language owner; workshop-rs remains the canonical Workshop owner.