Avoid blocking WebView2 creation with message pump

[satoshi-assistant]

Why

On Windows, Ableton Live can intermittently crash when an embedded plug-in editor is opened/closed rapidly. The crash is triggered around WebView2 creation: the current Windows backend synchronously waits for environment/controller callbacks using a nested message pump, so host GUI lifecycle callbacks can be dispatched while set_parent / show is still on the stack.

This patch moves WebView2 creation to callback continuation style instead of waiting. That makes the diff larger than a local lock or debounce workaround because InnerWebView::new can now return before the native WebView2 controller exists, so the Windows backend needs explicit pending state for operations that may arrive during creation.

Summary

• Replace synchronous WebView2 environment/controller creation waits with callback-driven continuation.
• Serialize WebView2 controller creation on the UI thread so only one controller creation is outstanding at a time.
• Keep WebView operations tolerant while the controller is still pending, applying queued bounds/navigation after creation completes.
• Make the Windows controller() extension return Option because the controller may now be pending.
• Add comments at the state/continuation boundaries explaining why the async structure is required.
• Keep the MSRV test matrix on Rust 1.77-compatible locked dependencies and pin the docs job to a nightly that supports the existing docs-only dependency attributes.

Validation

• cargo fmt --all -- --check passed.
• cargo check in wry passed.
• Used from wrac-plugin-template via local patch.
• cargo check -p wrac_wxp_gui -p wrac_gain_plugin --all-targets passed.
• cargo xtask build --release --target=clap,vst3 passed.
• Windows Ableton Live rapid editor open/close repro no longer crashes in local testing.