windows: enable winapi std for RawHandle interop

[iiTONELOC]

Cargo resolver 2 keeps features enabled only by dev-dependencies out of normal dependencies.

Under resolver 2, a Windows consumer fails at DeviceCapabilities::new(self.file.as_raw_handle()) because core::ffi::c_void and winapi::ctypes::c_void are different types. The package's legacy-resolver dev build hides this because rpassword enables winapi/std.

Enabling std on the direct Windows winapi dependency makes the raw-handle types compatible without relying on feature unification from an unrelated dev-dependency.

A minimal resolver-2 consumer on Rust 1.97 targeting x86_64-pc-windows-msvc fails before this patch and passes afterward. cargo test --features crypto_dummy --no-default-features also passes.

[micolous]

A minimal resolver-2 consumer on Rust 1.97 targeting x86_64-pc-windows-msvc fails before this patch and passes afterward.

Your change seems reasonable, but can this be tested in CI? Maybe using the ctap2 example?

Just as a PSA, as this is marked as a blocker by other projects: since Windows 10 v1903 (released in 2019), user-space applications can't directly communicate with USB authenticators unless running as Administrator. This breaks the library on Windows for most users.

Firefox uses Windows' platform WebAuthn APIs directly where they're available, and has similar wrappers for Android and macOS. These won't be supported by authenticator-rs.

Applications that support Windows should migrate to the Windows WebAuthn APIs, and shouldn't depend on authenticator-rs on Windows. Windows' APIs also support BLE, caBLE, NFC, smart card and TPM transports, running over RDP and credential manager plugins.

[iiTONELOC]

Thank you for the PSA. It saved me time. I assumed that authenticator-rs provided a portable Windows path. I now understand that Windows applications should use the platform WebAuthn APIs.

I added x86_64-pc-windows-msvc to the existing CI matrix. It uses the existing crypto_dummy build, test, and Clippy steps.

cargo test compiles the ctap2 example. The example uses rpassword, which enables winapi/std and masks this failure. An exact consumer test requires a normal dependency graph without that dev-dependency. Would the MSVC matrix coverage be sufficient, or would you prefer a dedicated consumer check?