Avoid JSRuntime cancellation race with EndInvokeJS

[alirezafzali]

Avoid JSRuntime cancellation race with EndInvokeJS

• You've read the [Contributor Guide](https://github.com/dotnet/aspnetcore/blob/main/CONTRIBUTING.md) and [Code of Conduct](https://github.com/dotnet/aspnetcore/blob/main/CODE-OF-CONDUCT.md).
• You've included unit or integration tests for your change, where applicable.
• You've included inline docs for your change, where applicable.
• There's an open issue for the PR that you are making. If you'd like to propose a new feature or change, please open an issue to discuss the change or find an existing issue.

Summary of the changes

Avoid race between JSRuntime cancellation and EndInvokeJS

Description

This change fixes a race condition in Microsoft.JSInterop.JSRuntime where both the cancellation callback and EndInvokeJS could concurrently attempt to complete the same TaskCompletionSource.

The issue was reported in dotnet/maui because the visible crash occurs in BlazorWebView, but the underlying race condition exists in Microsoft.JSInterop.JSRuntime within aspnetcore.

Previously, the cancellation callback captured the local TaskCompletionSource directly and called TrySetCanceled, while EndInvokeJS could simultaneously remove the same task from _pendingTasks and attempt to complete it via SetResult or SetException. In some cases this resulted in double-completion and an unhandled exception.

This change updates the cancellation path to first atomically remove the task from _pendingTasks using TryRemove. Only the code path that successfully removes the task is allowed to complete it.

Additionally, the EndInvokeJS exception handling path was hardened to use non-throwing completion semantics.

Regression tests were added to verify:

• cancellation followed by EndInvokeJS
• successful EndInvokeJS followed by cancellation
• failed EndInvokeJS followed by cancellation

Fixes dotnet/maui#31943

[alirezafzali]

@dotnet-policy-service agree