[design] Re-evaluate Workshop → OPY reconstruction scope after workshop-rs rebaseline

[Teakowa]

Related: #1, #8
Depends on: #52

Goal

Re-evaluate the current decompilation/workshop-to-opy blocker after the workshop-rs dependency rebaseline and produce one reviewed reconstruction contract before any implementation tree is created.

Context

compatibility/support-matrix.json currently marks decompilation/workshop-to-opy as lowering-dependent with wording that defers work until a canonical Workshop semantic representation exists. opy-rs already integrates with canonical workshop-rs WIR, and #52 will move that integration from the stale 0.1.1 baseline to the current published Workshop contract.

The existing blocker note may therefore be stale. This issue must determine current reality rather than assuming either that reconstruction is ready or that it remains blocked.

Separately, the existing decompilation/roundtrip-boundary decision remains authoritative for this spike: arbitrary .ws decompilation/reconstruction is not being reopened. The question here is only whether a scoped canonical Workshop semantic/WIR → OPY reconstruction path can now be defined.

This is intentionally a single design spike. Do not create implementation sub-issues from it until the design conclusion is reviewed and accepted.

Scope

• After [integration] Rebaseline opy-compiler on current workshop-rs release #52, inspect the current workshop-rs WIR/source/provenance contracts and determine whether they are sufficient inputs for scoped Workshop → OPY reconstruction.
• Define the reconstruction target in terms of semantic equivalence and useful source structure, not literal recovery of the original OPY source.
• Define what a meaningful round-trip contract would test, including which direction(s) are authoritative and how semantic equivalence is judged.
• Define how canonical Workshop identity and available provenance would map into OPY semantic/source constructs.
• Identify concrete missing contracts, if any, and assign ownership to workshop-rs or opy-rs rather than adding cross-repository workarounds.
• Reconcile the decompilation/workshop-to-opy support-matrix blocker wording with the resulting evidence while preserving the existing arbitrary .ws decompiler non-goal.

Non-goals

• No reconstruction implementation in this issue.
• No implementation sub-issues until this spike is reviewed.
• No arbitrary .ws decompiler or promise to reconstruct arbitrary Workshop text.
• No promise to recover comments, formatting, macro structure, source abstractions, or original naming that Workshop has already lost.
• No full-file round-trip/pretty-printer requirement for agent source editing.
• No byte/text identity requirement.

Acceptance criteria

• A concise design doc or ADR is merged in opy-rs with one explicit conclusion:
  • ready to implement — the scoped WIR → OPY reconstruction contract and test boundary are defined; or
  • still blocked — the precise missing contract, owner, and unblocking evidence are identified.
• decompilation/workshop-to-opy support-matrix wording reflects that conclusion rather than the stale assumption.
• decompilation/roundtrip-boundary continues to state that arbitrary .ws decompilation is out of scope unless a separate reviewed architecture decision explicitly changes it.
• No implementation tree is created as part of this spike.
• Any cross-repository prerequisite respects semantic ownership and has a separately reviewable contract.