Bootstrap and resolve the first-party OPY provider

[Teakowa]

Parent: #242
Depends on: #240
Integrates with: #243

Goal

Implement the approved first-party OPY provider resolution/bootstrap path so Wright can use a current opy-rs provider without linking OPY implementation releases into the Wright binary release cadence.

Context

#240 now defines the distribution contract: first-party OPY provider artifacts come from wrightkit/opy-rs GitHub Releases; Wright resolves an explicit provider first, then an installed active provider, then lazily bootstraps a missing provider; installed providers are reused offline; normal source commands do not poll for updates.

This issue is limited to resolving a verified local OPY provider executable and handing it to the existing LPP runtime. Source entry/project semantics remain owned by #243 and opy-rs.

Scope

• Resolve an explicitly configured local OPY provider executable first.
• Resolve an already installed active first-party OPY provider from the approved per-user provider store.
• On first OPY use, bootstrap a missing provider from the opy-rs GitHub Release artifact for the current supported target.
• Verify the published SHA-256 checksum before activation.
• Install through temporary/versioned state and activate atomically so partial or failed downloads never become active.
• Preserve the previous active provider if an update/install fails.
• Reuse an installed provider offline with no update/network check on ordinary source commands.
• Provide the explicit provider-update operation required by Design lightweight first-party language provider distribution and lazy loading #240 without periodic/TTL polling.
• Surface missing-provider, offline, download, integrity, install, spawn, and protocol/capability failures explicitly through Wright's structured error path.
• Ensure raw Workshop and unrelated commands perform no OPY provider network/bootstrap work.
• Pass the resolved executable into the existing LPP/provider runtime rather than creating another process/wire implementation.

Non-goals

• Implementing the OPY provider binary itself; that belongs to opy-rs#170.
• Source/project loading, #!mainFile, includes, preprocessing, or OPY semantics in Wright.
• Creating a registry, dependency solver, project lockfile, marketplace, or generic plugin manager.
• Updating providers automatically on every Wright invocation or through a TTL/background policy.
• Implementing DEL/OSTW provider bootstrap in this milestone.
• Changing LPP wire semantics for distribution convenience.
• Duplicating runtime capabilities/protocol compatibility in release metadata.

Acceptance criteria

• A clean Wright installation can encounter an OPY workflow, discover that the first-party provider is missing, and bootstrap the correct provider artifact from the approved opy-rs release source.
• Resolution precedence is explicit local provider > installed active first-party provider > lazy bootstrap.
• An already installed provider is reused without network access.
• An explicit local provider executable can be selected without first-party download behavior.
• Downloaded artifacts are checksum-verified before activation and partial/failed installs cannot become active.
• Failed updates preserve the previous working active provider.
• Normal check, compile, lint, and analyze invocations do not contact the release source merely to check for updates.
• Raw Workshop workflows do not resolve/download/spawn an OPY provider.
• Integrity failure, unsupported platform, offline-without-cache, download/install failure, spawn failure, and protocol/capability mismatch remain explicit machine-readable failures; none silently falls back to static OPY semantics.
• Successful resolution returns a local executable usable by the shared provider boundary in Converge source-language workflows on an explicit provider boundary #243.
• The resolved executable is consumed by the existing LPP runtime / ProviderRegistry; no second provider execution abstraction is introduced.
• No provider dependency graph, package index, or Wright project lock state is introduced.
• Independent regression evidence covers clean install and offline reuse.
• Implementation ablation that disables provider resolution/bootstrap causes the relevant clean-install real-project workflow to fail again.

Dependencies / ownership

• Parent: Make Wright CLI CI-ready for real Workshop and OverPy projects #242.
• Design lightweight first-party language provider distribution and lazy loading #240: approved distribution and update contract.
• Converge source-language workflows on an explicit provider boundary #243: entry-based Wright product/provider seam.
• opy-rs#170: provider executable and release artifacts.
• language-provider-protocol: runtime wire negotiation only; distribution is not owned there.

Readiness

Ready. Artifact source, resolution precedence, local state purpose, integrity behavior, and explicit update policy are resolved by #240. Implementation should remain OPY-specific until the pinned real-project workflow proves a repeated need for broader abstraction.

[Teakowa]

Current reality update (2026-09-03): the resolver implementation is on main (explicit executable -> active installed provider -> lazy bootstrap, checksum validation, staged/atomic install, offline reuse, explicit update). The real bootstrap acceptance path is currently blocked by distribution state: opy-rs/releases/latest is v0.1.12 and exposes no opy-provider-* release assets.

Keep #244 open. Next evidence is to publish a provider-enabled OPY release (current release vehicle: wrightkit/opy-rs#169) and then independently verify the production resolver against that real release: clean bootstrap, target-specific archive/checksum selection, activation, offline reuse, explicit update, raw Workshop never touching the provider path, and the required bootstrap/activation ablation.