[windows] awaiting UserConsentVerifier async ops via NSWinRT.toPromise panics the process (cross-isolate PinnedRef) #11627

Summary

Awaiting Windows.Security.Credentials.UI.UserConsentVerifier.CheckAvailabilityAsync (and RequestVerificationAsync) through NSWinRT.toPromise terminates the process with a native v8 panic — a JS try/catch cannot intercept it:

[NativeScript] PANIC at v8-147.4.0/src/scope.rs:943:7:
v8::scope::PinnedRef<'_, v8::scope::HandleScope<'_, ()>> and Context do not belong to the same Isolate

Other WinRT asyncs on the same call path (StorageFile ops, PasswordVault ops) complete through toPromise without crashing, so this is specific to UserConsentVerifier's completion context.

Real-world use case affected

An app-level biometrics facade (@octane-xplat/biometrics) implementing Windows Hello verification on NativeScript Windows: biometrics.isAvailable() → CheckAvailabilityAsync, biometrics.verify(reason) → RequestVerificationAsync. Calling these from a packaged app's service/command context hard-crashes the process — the user sees the app silently die mid-operation, and no error surface (no rejection, no exception) reaches JavaScript.

Evidence

• Packaged MSIX org.octanexplat.windows61 1.0.0.233, x64, on a NativeScript Windows preview runtime (Rust/v8 host; crash logged to nativescript-crash.log inside the package LocalState).
• Repro path: a polling command loop dispatched an async service spec on the app's JS thread; the spec's first NSWinRT.toPromise(api.CheckAvailabilityAsync()) crashed. Earlier service specs in the same app using PasswordVault add/retrieve (also toPromise-awaited) completed normally.
• Working route: a managed C# helper enqueues UserConsentVerifier calls on the captured DispatcherQueue and exposes a polled string state — that path works, but only because no WinRT async crosses NSWinRT.toPromise in JS.

Expected

toPromise resolves or rejects on the calling isolate; a class that cannot be awaited should fail safely (error or unprojected stub), never panic the process.