Run real OPY check and compile workflows through the first-party provider

[Teakowa]

Parent: #242
Depends on: #243, #244, wrightkit/opy-rs#170, #259, wrightkit/opy-rs#188

Goal

Make wright check and wright compile use the first-party OPY provider for real OverPy projects, preserving owner diagnostics/project behavior and producing CI-ready Wright results without a static semantic fallback.

Context

check and compile are the first direct product slice of the provider milestone. They should prove that a clean Wright installation can acquire/use the OPY provider and process the same real projects that currently rely on the upstream OverPy compile gate.

Bastion and Overwatch-AI-PVE are validation targets, not sources of Wright-specific compatibility hacks.

Scope

• Route OPY wright check through the explicit provider boundary from Converge source-language workflows on an explicit provider boundary #243 and the resolved provider from Bootstrap and resolve the first-party OPY provider #244.
• Route OPY wright compile through the same provider/project model.
• Preserve project root, reachable source identities, owner diagnostics, and relevant locale/options from the CLI input through the provider request/result.
• Map provider/process failures into existing Wright structured result/exit contracts without parsing human messages.
• Render successful compile output through the documented Wright stdout/output-file contract.
• Keep CI/non-TTY/JSON behavior deterministic and free of interactive progress noise.
• Verify behavior on pinned revisions of OWBastion/Bastion and Teakowa/Overwatch-AI-PVE using their real project entry points and roots/options.
• When a real-project failure belongs to OPY source/compiler semantics, file/fix it in opy-rs; when it belongs to canonical Workshop semantics, route it to workshop-rs.

Non-goals

• Implementing OPY parsing, preprocessing, project loading, semantics, or lowering in Wright.
• Falling back silently to the current static OPY adapter when provider execution is unavailable or refused.
• Requiring byte/text identity with upstream OverPy output when the declared compatibility contract only requires observable/canonical semantic equivalence.
• Implementing Wright lint/analyze provenance; that is tracked separately.
• Migrating Bastion/Overwatch-AI-PVE CI before Make Wright CLI CI-ready for real Workshop and OverPy projects #242 final verification.
• Adding unrelated compile options or CLI polish.

Acceptance criteria

• wright check on the pinned Bastion and Overwatch-AI-PVE project revisions executes through the first-party OPY provider and reports owner diagnostics against the correct project source identities.
• wright compile on the same revisions executes through the provider and produces valid Workshop output for the declared supported surface.
• Project root/includes/preprocessing behavior is supplied by opy-rs; Wright does not recreate an OPY project loader.
• A provider source error produces Wright failure output with the preserved source diagnostic rather than a provider/process error.
• Missing provider, provider refusal, protocol/capability mismatch, process failure, and owner source/compiler diagnostics remain machine-distinguishable.
• No provider failure silently falls back to static Wright OPY semantics.
• --format json, plain/generic CI, and GitHub Actions rendering preserve the existing deterministic Wright contracts.
• Raw Workshop check / compile behavior remains regression-green and does not require OPY provider activity.
• Real-project failures discovered in this work are fixed in the owning repository and rerun through this Wright workflow before being considered resolved.
• Independent verification reruns both real projects after implementation.
• Implementation ablation that removes/bypasses the provider-backed OPY path causes the pinned real-project regression evidence to fail again.

Dependencies / ownership

• Parent: Make Wright CLI CI-ready for real Workshop and OverPy projects #242.
• Converge source-language workflows on an explicit provider boundary #243 owns the explicit Wright provider/source boundary.
• Bootstrap and resolve the first-party OPY provider #244 owns first-party provider resolution/bootstrap.
• wrightkit/opy-rs#170 owns the first-party OPY provider and project behavior.
• Synchronize Wright's Workshop dependency graph on workshop-rs 0.1.18 #259 owns synchronization of Wright's canonical Workshop consumer with the released contract used by the provider before final parser-failure classification.
• wrightkit/opy-rs#188 owns compile-time resolution of valid OverPy settings expressions before canonical Workshop emission.
• wrightkit/opy-rs#157 owns only blockers demonstrated to belong to OPY compiler/lowering convergence after valid real-project classification.
• workshop-rs owns demonstrated canonical Workshop defects.

[Teakowa]

Current reality update (2026-09-03): prerequisites are partly on main, but the production OPY CLI cutover is not implemented yet.

SessionConfig::default() selects SourceBackend::Native. The ordinary CLI copies --opy-provider into configuration but still constructs CompilerSession::new(config) without switching to the provider backend or injecting a concrete SourceProvider. The existing source-provider driver tests use an injected recording provider, while the generic LPP tests exercise ProviderRegistry separately; neither proves the real OPY production workflow.

The clean bootstrap dependency is also not consumable yet because the current latest OPY release (v0.1.12) has no provider artifacts.

Treat #245 as the next product integration task after the release/#244 gate: connect the resolved first-party OPY LPP process to the production SourceProvider path, keep entry/project semantics owner-side, prohibit legacy/static fallback, and independently run pinned Bastion and Overwatch-AI-PVE wright check / wright compile plus the required ablation.