Remove residual Wright-owned OPY IR/lowering shim after owner cutover

[Teakowa]

Goal

Remove residual Wright-owned OPY IR/lowering implementation and Workshop re-export shims that belong to opy-rs / workshop-rs, while retaining only integration/tooling types that Wright actually owns.

Context

The source-language ownership boundary requires Wright to consume released owner contracts rather than carry an authoritative OPY HIR/lowering implementation or a second Workshop abstraction layer.

Residual compatibility or migration types may remain only where they serve a concrete Wright-owned integration contract. Historical naming alone is not sufficient reason to remove a type, and historical migration shims are not sufficient reason to keep one.

Scope

• Identify wright-ir items still consumed by Wright product/integration code.
• Remove residual OPY HIR/lowering implementation that is authoritative in opy-rs.
• Remove Workshop-type/infrastructure re-export shims where consumers can use canonical workshop-rs contracts directly.
• Retain only Wright-owned integration/tooling types with an actual consumer contract; relocate or rename them where necessary without reintroducing source-language ownership.
• Preserve existing Wright integration behavior and machine contracts.

Non-goals

• No OPY semantic or lowering changes in Wright.
• No redesign of opy-rs, workshop-rs, provider architecture, or LPP.
• No unrelated IR/framework cleanup.
• No requirement to remove a type solely because its historical name contains ir; ownership and actual consumers decide the boundary.
• No priority/readiness tracking in this issue body.

Acceptance criteria

• Wright contains no authoritative OPY HIR or OPY -> Workshop lowering implementation duplicated from opy-rs.
• Wright contains no compatibility-only Workshop adapter/re-export layer where direct canonical workshop-rs consumption is sufficient.
• Any retained shared/integration types have a concrete Wright-owned consumer purpose and do not duplicate canonical language semantics.
• Existing OPY, DEL, raw Workshop, CLI, embedding, and integration gates remain regression-green.
• No second canonical Workshop or OPY implementation appears.

Execution priority should be determined from current semantic blockers and GitHub planning metadata rather than encoded in this issue description.