feat: route OPY workflows through first-party provider

[e54-bot]

Summary

• route ordinary .opy check and compile workflows through first-party LPP 1.1 project loading;
• keep raw Workshop in-process and non-check OPY workflows explicit until a canonical provider WIR handoff is available;
• preserve owner diagnostics and source identities, and reject provider failures without native fallback;
• avoid caching check-only results as an empty WIR; provider WIR is reusable only after canonical compile;
• enable ureq native certificate loading so clean packaged installs can acquire the OPY provider through platform trust stores without weakening HTTPS verification.

Verification

• cargo fmt --all
• git diff --check
• cargo test --workspace — all tests passed, 2 external-corpus tests ignored
• cargo clippy --workspace --all-targets --all-features -- -D warnings
• compatibility evidence tests — 2 passed
• CLI tests — 22 unit tests and 43 integration tests passed
• provider-backed N-level gate — 6/6 fixtures passed, including real-world/overpy-cake; recorded snapshots unchanged
• the gate normalizes only the documented semantic alias Up ↔ Vector(0, 1, 0)
• entry-forwarding ablation caused both Bastion and OW1 provider checks to fail closed with ablation-entry-disabled and exit 4
• python3 scripts/test-npm.py --binaries-dir target/debug — clean isolated npm install, npx wright compile, npx wright check, Node API, and multi-platform archive packaging checks passed

Real-project status

• Bastion src/main.opy provider check passes with zero diagnostics.
• Bastion compile currently exposes an opy-rs owner artifact issue: #!define symbols remain in settings and Wright rejects the resulting non-canonical Workshop artifact.
• OW1 ow1-emulator/src/1v1_main.opy currently exposes opy-rs owner diagnostics for an unsupported append receiver and an owner warning surfaced as an error.

These owner-side blockers remain explicit; Wright does not add a semantic workaround or fallback. The remaining #245 acceptance work is to fix those owner issues and rerun the real-project workflows.

Refs #245

[Teakowa]

See inline findings.

[Teakowa]

Major — The provider cutover fixes the two previous findings, but the new head introduces a required CI regression: OPY integration (N-level + owner) now fails in scripts/v1-gates.py because real-world/overpy-cake diverges after normalization, while the previous head was green. Fix the post-cutover OPY gate/workflow so it validates the intended provider-backed contract and returns green without weakening the compatibility expectation or simply accepting a changed snapshot.

[Teakowa]

Major — The provider-backed N-level regression is fixed, but the cutover still breaks the clean installed CLI path required by #245. In the current CI, the isolated npm package installs successfully, then npx wright compile compatibility/fixtures/synthetic/basic-rule/source.opy --profile compat exits 4 on macOS (and the Windows distribution smoke fails at the same stage), while Ubuntu passes. Fix the provider acquisition/resolution path for packaged clean installs so ordinary OPY compile/check works without a preinstalled/manual provider, and restore the distribution matrix without falling back to native OPY semantics.