feat(provider): resolve first-party OPY providers

[e54-bot]

Summary

• Add first-party OPY provider resolution with explicit local, installed-active, and bootstrap precedence.
• Verify provider archives with SHA-256, install through versioned staging, and activate atomically while preserving the previous provider on failure.
• Add wright provider update opy and --opy-provider, and pass the resolved executable through the existing ProviderRegistry.

Validation

• cargo fmt --all -- --check
• cargo clippy --workspace --all-targets --all-features -- -D warnings
• cargo test --workspace --all-targets --all-features </dev/null
• Clean-install, offline-reuse, and bootstrap-ablation tests

Scope note

wright#243, language-provider-protocol#16, and opy-rs#170 are still open. This PR delivers the #244 resolver/bootstrap and existing LPP handoff; the full normal OPY workflow cutover remains coordinated with those dependencies.

Refs #244

[Teakowa]

Major — crates/wright-driver/src/opy_provider.rs::target_for

The resolver hard-codes Windows as unsupported, but Wright currently ships x86_64-pc-windows-msvc, while #240/#244 require first-party provider resolution for supported Wright targets. The new test also locks this mismatch in by asserting Windows is unsupported, so CI cannot catch the product-contract regression.

Support the Windows release target (including its executable/archive handling) or change the approved supported-target contract before merging.

[Teakowa]

Major — crates/wright-driver/src/opy_provider.rs::OpyProviderResolver::target

Windows is still rejected before the new ZIP/.exe path can run: target_for("windows", "x86_64") now returns x86_64-pc-windows-msvc, but target() still only accepts the three Linux/macOS triples. The new Windows test calls install_archive directly, so it bypasses this resolver gate and CI remains green.

Add x86_64-pc-windows-msvc to the resolver's supported targets and cover Windows through resolve/update, not only direct archive installation.

[Teakowa]

LGTM