Remove `frontend` architecture terminology and complete source-language ownership cutover

[Teakowa]

Goal

Remove frontend as a durable WrightKit architecture/product concept in Wright and finish the consumer-side cleanup so Wright depends on the independently owned OPY/DEL implementations rather than presenting wright-opy / wright-ostw as native source-language frontends.

Context

Wright's current README correctly defines Wright as the unified tooling/integration product downstream of opy-rs, del-rs, and workshop-rs, but the workspace still contains wright-opy and wright-ostw crates whose package descriptions call them Wright-native frontends. This is both terminology drift and an ownership/cutover mismatch.

The durable model is:

opy-rs / del-rs / workshop-rs -> Wright tooling/services -> CLI/LSP/CI/agent/embedding

Wright may contain adapters, projections, and tooling-specific analysis, but it must not retain a second authoritative OPY or DEL/OSTW language implementation.

Cross-repository language-owner cleanup:

• Retire frontend as an architecture boundary and consolidate the OverPy language implementation opy-rs#62
• Retire frontend as a durable architecture term for the DEL/OSTW implementation del-rs#52

Existing related cleanup work in Wright includes #155 (adapter/shim removal) and #182 (residual OSTW owner-style evidence). This issue must coordinate with those rather than recreate parallel ownership.

Scope

• Remove frontend as a durable architecture noun from current Wright README/docs/ADR/AGENTS-facing architecture guidance and active planning material; describe concrete source-language capabilities and integration roles instead.
• Audit wright-opy and wright-ostw call sites and classify each as language ownership, Wright-specific tooling projection, compatibility residue, or temporary adapter.
• Migrate source-language parsing/semantic/HIR ownership to the released/explicit opy-rs and del-rs contracts as those owner-side changes land.
• Remove wright-opy / wright-ostw once their remaining owner-style responsibilities have been migrated. If a Wright-specific adapter remains necessary, it must be narrowly named for its actual integration/tooling role and must not recreate language semantics.
• Remove duplicate source-language compatibility/evidence ownership in accordance with Track removal of residual OSTW owner-style evidence after del-rs migration #182 and keep only Wright consumer/integration evidence that a Wright product test actually consumes.
• Reconcile workspace dependencies and public documentation so the code graph matches Wright's documented downstream-consumer architecture.
• Update active issues whose current acceptance criteria still treat a Wright-native frontend as the intended end state.
• Preserve explicit LPP/provider terminology only where it denotes a real process/API integration role; provider is not a replacement name for frontend or a source-language owner.
• Keep historical closed issue/PR text unchanged unless a live document references it as current architecture.

Non-goals

• Reimplementing missing OPY/DEL semantics inside Wright to make the cutover appear complete.
• Deleting a legacy implementation before the owning repository exposes the capability required by the current Wright product path; such a gap must remain explicit and be fixed in the owning repository.
• Renaming wright-opy / wright-ostw while preserving the same owner-style implementation under a new label.
• Changing LPP solely for terminology symmetry.
• Broad unrelated Wright crate consolidation or architecture cleanup.

Acceptance Criteria

• Current Wright architecture/docs no longer define or rely on frontend as a WrightKit layer or product concept.
• Wright's dependency/code graph matches the documented ownership direction: source-language semantics come from opy-rs / del-rs; canonical Workshop semantics come from workshop-rs.
• No Wright crate remains the authoritative parser/semantic/HIR owner for OPY or DEL/OSTW after the corresponding owner-side capability is available.
• wright-opy and wright-ostw are removed, or any retained replacement is demonstrably a narrow Wright integration/tooling adapter with no duplicated language semantics.
• check, inspect, lint/analyze inputs, source spans/provenance, and other affected Wright workflows have regression coverage across the owner implementation boundary.
• Unsupported owner-side capabilities fail explicitly; there is no hidden fallback to stale Wright-native language semantics.
• [v0.3] Remove workshop-rs adapter/shim once opy-rs extraction lands #155/Track removal of residual OSTW owner-style evidence after del-rs migration #182 are either completed by this coordinated cutover or updated so their remaining scope is non-duplicative and concrete.
• Current README/ADR/active issue wording consistently describes Wright as the tooling/integration consumer of three independently owned implementations.

Dependencies

• Retire frontend as an architecture boundary and consolidate the OverPy language implementation opy-rs#62
• Retire frontend as a durable architecture term for the DEL/OSTW implementation del-rs#52
• Existing Wright cleanup tracks [v0.3] Remove workshop-rs adapter/shim once opy-rs extraction lands #155 and Track removal of residual OSTW owner-style evidence after del-rs migration #182 where their acceptance remains applicable.