[v0.2] Rebaseline language ownership and licensing boundaries

[Teakowa]

Release coordination: #135

Goal

Record the durable multi-repository ownership and licensing model before compiler/core code extraction and cutover proceed.

Scope

• Add a new ADR that amends ADR-0008 frontend-ownership wording while preserving tooling-first priority, semantic compatibility, Workshop-centered interoperability, and source-oriented mutation.
• Record repository ownership:
  • wrightkit/workshop-rs owns canonical Workshop semantics/catalog/WIR;
  • wrightkit/language-provider-protocol owns the neutral provider protocol contract;
  • wrightkit/opy-rs owns first-party OPY language semantics/implementation;
  • wrightkit/del-rs owns the independent DEL/OSTW-compatible implementation;
  • wrightkit/wright owns tooling, orchestration, generic edit-transaction safety, agent/embedding APIs, language services, and integration adapters.
• Define LPP as the stable process boundary rather than Rust trait/dylib/FFI ABI.
• Record provider-specific provenance/licensing strategy instead of one repository-wide frontend assumption.
• Rebaseline Wright licensing/architecture docs to distinguish current migration state from target ownership.
• Record that provider implementation and provenance policy belongs to each owning repository rather than Wright.
• Document dependency direction so providers/core do not depend back on Wright tooling internals.

Non-goals

• Moving implementation code in this issue.
• Final Wright relicensing before provenance/contributor audit.
• Designing LPP request/response schemas; owned by language-provider-protocol.
• Expanding language compatibility.

Acceptance criteria

• An accepted ADR defines the repository/component ownership and process boundaries above.
• ADR-0008 no longer implies that the Wright tooling repository must permanently own OPY/DEL compiler implementations or canonical Workshop semantics.
• Licensing/provenance docs distinguish provider-specific provenance/compatibility work from shared core/protocol goals without claiming a legal safe harbor.
• Current implementation state and target architecture are both documented without conflation.
• Existing tooling-first and semantic-compatibility contracts remain normative.