Fix JSInterop DefaultAsyncTimeout swallow issue

[GOVINSAGA]

Fixes #21384.

Root Cause: When DefaultAsyncTimeout fires, the CancellationTokenSource triggers tcs.TrySetCanceled(), producing a task with IsCanceled = true. ComponentBase then swallows it in its catch blocks (since it ignores canceled tasks to handle normal component disposal).

My approach: Modify only the InvokeAsync overload that creates the DefaultAsyncTimeout CTS. Wrap the inner call in a try/catch that catches OperationCanceledException only when cts.IsCancellationRequested is true, and re-throws as a JSException.

Why this avoids the previous issues:

• No breaking changes — the InvokeAsync(CancellationToken) overload is untouched
• ComponentBase won't swallow it — JSException produces a faulted task (IsCanceled = false)
• User-supplied tokens still behave as before
• No new public API types required
• No changes to ComponentBase.cs

[dotnet-policy-service]

Thanks for your PR, @GOVINSAGA. Someone from the team will get assigned to your PR shortly and we'll get it reviewed.

[javiercn]

Hmm, not sure how I feel about this one.

This now means that if a JS interop call timed out, ComponentBase will throw instead of no-op, which might result in the session terminating (the circuit getting disposed).

Changing the exception is not a breaking change in the strict sense but its still a behavior breaking change. Anyone that used to do

try
{
}
catch (OperationCanceledException ex)
{
}

will now have to update to JSException. We might want to consider an AppCompat switch here just in case, but no need to do that right now.

That said, reading through #21384 (comment) (might want to include this on the description here next time) I think it's ok. I would suggest that for completeness we set the InnerException to the TCS, as that makes it easier to distinguish against another JSException cause.