Consume source-language owners through their consolidated public Rust APIs

[Teakowa]

Goal

Make Wright consume opy-rs and deltin-rs through their intentional owner-level public Rust contracts instead of assembling source-language implementation sub-crates or backend details itself, and keep Wright's own workspace decomposition from accidentally becoming a public crates.io surface.

Context

Wright's source-language adapters are integration layers, not language owners. Today the OPY path still exposes repository implementation decomposition to Wright: the workspace pins both opy-rs and opy-compiler, and wright-opy depends directly on opy-rs, opy-compiler, and workshop-rs. wright-ostw similarly depends on both deltin-rs and workshop-rs.

Some direct workshop-rs use is legitimate for Wright-owned raw Workshop or cross-language tooling. It should not be required merely because a source-language owner lacks a complete public compile/tooling API.

The owner repos are being aligned so a Rust consumer can use opy-rs or deltin-rs as the source-language contract without learning their internal compiler/CLI/module packaging.

Wright itself currently contains many internal workspace crates (wright-core, wright-ir, wright-driver, language adapters, analyzer/transform/LSP/CLI crates, and others). Current release automation distributes Wright binaries and package-manager/npm artifacts rather than publishing those crates to crates.io, but Cargo package defaults do not by themselves express that these repository boundaries are internal.

Scope

• After the corresponding owner releases are available, migrate wright-opy to the consolidated opy-rs public API and remove the direct opy-compiler dependency.
• Consume DEL/OSTW check/inspect/compile capabilities through the consolidated deltin-rs public API as that contract becomes available.
• Audit direct workshop-rs dependencies in wright-opy and wright-ostw: retain them only where Wright itself intentionally consumes canonical Workshop semantics, not where they compensate for a missing source-language owner API.
• Keep wright-opy / wright-ostw as narrow adapters for Wright IR/tooling contracts rather than source-language compiler assembly layers.
• Preserve structured diagnostics, provenance, compile results, and canonical semantic identities across the owner boundary.
• Audit Wright's own workspace package publication intent. Internal implementation/test/support crates must be explicitly non-publishable unless a separately reviewed public Rust embedding/package contract justifies publication.
• Do not make third-party consumers depend on wright-core, wright-ir, wright-driver, language adapters, or other repository decomposition merely because those crates exist internally.
• Keep the current binary/package-manager release flow independent from any future public Rust embedding contract; introducing such a contract requires an intentional public API decision rather than accidental cargo publish eligibility.
• Update workspace dependency pins and integration documentation to reflect the public owner contracts and package intent.

Non-goals

• Moving OPY or DEL/OSTW semantics into Wright.
• Removing legitimate direct workshop-rs use from Wright-owned raw Workshop, cross-language, lint/analysis, or canonical semantic workflows.
• Redesigning Wright's internal crate architecture unrelated to source-language owner consumption or package-publication intent.
• Implementing missing owner capabilities locally while waiting for the owner release.
• Coupling Wright to CLI packages from source-language repositories.
• Creating or naming a new public Wright Rust embedding crate without a separately approved product/API contract.

Acceptance criteria

• wright-opy no longer depends on opy-compiler; OPY integration uses the released opy-rs owner API.
• Wright does not depend on source-language CLI or private implementation packages.
• DEL/OSTW integration uses deltin-rs owner APIs for source-language/compiler behavior rather than reconstructing that behavior in Wright.
• Any remaining direct workshop-rs dependency in source-language adapters has a concrete Wright-owned canonical Workshop use and is not an owner-capability workaround.
• Wright's current internal workspace crates are explicitly non-publishable unless an intentionally supported public package contract exists for that crate.
• Current Wright releases continue to publish the intended executable/package-manager surfaces without implying crates.io stability for internal workspace crates.
• Existing Wright check/inspect/compile diagnostics, provenance, and integration behavior remain regression-green.
• No OPY/DEL/Workshop canonical semantics are duplicated in Wright as part of the migration.

Dependencies / ownership

• Depends on wrightkit/opy-rs#111 and a consumable release of its consolidated API.
• DEL/OSTW migration depends on wrightkit/deltin-rs#80 and the relevant compile contract from deltin-rs#33.
• Owner changes land and release first; Wright integrates only after those contracts are consumable.