Do not prevent rendering for router that has OnNavigateAsync when navigation already started during 404 re-execution.

In #24225 we blocked rendering for router that has OnNavigateAsync that is typically used for lazy loading actions. The reason was that rendering was throwing when triggered before with lazy loading finished: #24211.

With rendering blocked, 404 re-execution mechanism is not able to render the contents of 404 page. We need to implement logic to detect when re-execution has occurred and allow rendering in that specific case.

Description

• Prevents blocking rendering for routers with OnNavigateAsync in progress if Refresh is triggered by re-execution to a different component type.
• Implements component-type detection: Router compares the component type that triggered the pending OnNavigateAsync with the current route's component type. If they differ (indicating 404 re-execution to an error page), rendering is allowed. If they match (same-page lazy loading), rendering remains blocked.
• Added test for the issue: BrowserNavigationToNotExistingPath_ReExecutesTo404.
• Added comprehensive test for Don't render route component if OnNavigateAsync task in-progress #24225 that validates rendering waits for OnNavigateAsync completion during lazy loading: BrowserNavigationToLazyLoadedRoute_WaitsForOnNavigateAsyncGuard.

Fixes #63933

Possible Edge Cases Discussion

1. Multiple OnNavigateAsync handlers on same component (lazy-loading):
   E.g. when navigating from /products/1 to /products/2 (both render ProductsPage). Typically the assembly required for rendering is already loaded, so no risk of Lazy loading might encounter issues if host page rerenders during loading #24211 (exceptions during rendering because lazy loaded assembly is missing).

2. Re-execution to same component type:
   Real-world re-execution always targets dedicated error/404 components (e.g., /invalid-route re-executes to /not-found with NotFoundPage component). Same-component re-execution would require anti-pattern design (same component having @page "/users/{id}" and @page "/error" at the same time). In case of using this anti-pattern, the rendering would still be blocked.

3. Null RouteData during re-execution:
   IRoutingStateProvider only provides RouteData during endpoint/SSR rendering. After a page becomes interactive (Server Interactive via SignalR or WebAssembly), subsequent navigations are handled client-side by the Router component without going through the endpoint middleware. In these client-side navigation scenarios, RoutingStateProvider is null, which correctly falls back to the original blocking behavior.

4. Query/hash parameter changes (same route): Navigating from /products?page=1 to /products?page=2 renders the same component (ProductsPage). I was always blocked during pending OnNavigateAsync. Since providerRouteData.PageType == _previousOnNavigateTaskPageType, allowRenderDuringPendingNavigation is false, maintaining the original blocking behavior.