Decouple Wright from the static deltin-rs dependency #312

Goal

Remove Wright's build-time dependency on deltin-rs so Wright's direct canonical workshop-rs dependency can advance independently of the DEL/OSTW implementation release cadence.

Context

Wright currently links the DEL/OSTW implementation through its static wright-ostw integration. Because deltin-rs also consumes workshop-rs, that static Rust dependency makes Wright's canonical Workshop version depend on the DEL owner's migration schedule.

This coupling now blocks Wright from consuming the current canonical Workshop contract even though DEL/OSTW is not part of the provider-backed product milestone that established the first-party OPY path.

The durable ownership model is that Wright owns product/tooling integration, deltin-rs owns DEL/OSTW semantics and lowering, and workshop-rs owns canonical Workshop semantics. Source-language implementation release cadence must not prevent Wright from advancing its own direct canonical Workshop dependency.

Scope

• Remove the direct/build-time deltin-rs dependency from the shipped Wright dependency graph.
• Remove or disable the static DEL/OSTW integration path that requires linking the DEL implementation into Wright.
• Keep any retained Wright-owned DEL/OSTW-facing types or routing only where they have a concrete product/integration purpose and do not depend on DEL implementation semantics.
• When a DEL/OSTW workflow reaches a capability that no longer has an implementation available, return an explicit unsupported/provider-unavailable result rather than silently falling back to stale Wright-owned behavior.
• Preserve raw Workshop and provider-backed OPY workflows while allowing Wright's direct workshop-rs dependency to advance independently.
• Keep the resulting boundary compatible with the entry-based provider model defined by Converge source-language workflows on an explicit provider boundary #243 so future DEL/OSTW provider work can restore the capability without reintroducing build-time coupling.

Non-goals

• Implementing or distributing a DEL/OSTW LPP provider in this issue.
• Migrating deltin-rs to a newer workshop-rs API; that remains owner-side work.
• Reimplementing DEL/OSTW syntax, semantics, project loading, diagnostics, HIR, lowering, or Workshop compatibility in Wright.
• Adding a compatibility shim solely to keep the static DEL path linked.
• General Wright crate consolidation or unrelated dependency cleanup.
• Changing raw Workshop or OPY semantics.

Acceptance criteria

• The shipped Wright dependency graph no longer contains deltin-rs as a direct or transitive implementation dependency introduced by Wright's DEL/OSTW adapter path.
• Wright's direct workshop-rs dependency can be upgraded without Cargo resolution being constrained by deltin-rs's Workshop dependency.
• No DEL/OSTW source-language semantics are copied or recreated in Wright to replace the removed dependency.
• DEL/OSTW requests that require the removed implementation fail explicitly with a structured unsupported/provider-unavailable outcome; there is no silent static fallback.
• Existing raw Workshop and provider-backed OPY product workflows remain regression-green.
• Any retained wright-ostw code has a concrete Wright-owned integration purpose and does not link the DEL implementation; otherwise it is removed from the shipped path.
• Independent verification demonstrates that restoring the static deltin-rs edge recreates the Workshop-version coupling this issue removes.

Dependencies / ownership

• Converge source-language workflows on an explicit provider boundary #243 defines Wright's durable entry-based source-provider boundary.
• Remove frontend architecture terminology and complete source-language ownership cutover #227 owns the broader source-language ownership cutover and terminology cleanup.
• wrightkit/deltin-rs#107 owns migration of DEL/OSTW lowering to the canonical Workshop Program API and is not a prerequisite for this decoupling.
• Future DEL/OSTW provider implementation belongs to deltin-rs; Wright should consume it through the established provider boundary rather than restore a static implementation dependency.