[vendasankarsf3945]

[Wasm] Recover invalid cached boot resources

Summary

Fingerprint-named WebAssembly boot resources are loaded with cache: "force-cache". If the browser stores an unusable response for one of these resources, such as an empty response, non-success response, or a response rejected by integrity validation, subsequent application loads can continue reusing the same cached entry. The application then cannot start until the user manually clears the site's browser data.

Changes

This change adds cache recovery to the Mono and shared/native WebAssembly asset loaders.

For resources using force-cache, the loader now:

1. Performs the existing fetch without changing its request options.
2. Returns successful, non-empty responses unchanged.
3. If the fetch throws, returns a non-success response, or returns an explicitly zero-length response, retries the resource once with cache: "reload".
4. Propagates a failure from the recovery request without attempting another reload.

The recovery request preserves the existing URL, credentials, integrity metadata, content-type handling, and configured fetch abstraction. Resources that do not use force-cache retain their existing behavior.

The asset's cache mode is also changed to reload after an unusable cached response is detected, preventing the existing higher-level retry path from returning to the same invalid cache entry.

Testing

The browser test host can inject a bounded number of empty, cacheable responses for the client assembly. The added Chromium tests verify that:

• A fingerprinted application recovers from an empty cached assembly response and starts successfully.
• A failed recovery stops after one reload.
• A non-force-cache failure is not retried by this recovery path.
• The existing healthy-cache behavior remains unchanged.

Validated with the Wasm.Build.Tests real-browser Blazor test infrastructure using Chromium.

Fixes dotnet/aspnetcore#69488

[azure-pipelines]

Azure Pipelines:
Successfully started running 3 pipeline(s).
13 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.

[jkotas]

Fixes #69488

Is this the correct issue link?

[dotnet-policy-service]

Tagging subscribers to 'arch-wasm': @lewing, @pavelsavara
See info in area-owners.md if you want to be subscribed.

[pavelsavara]

The underlying problem of storing stale 404 or empty file via force-cache sucks.
I think we get TypeError: Failed to fetch in both cases, because of integrity, right ?
That should not be in the noRetryStatusCodes and so, we could set cache: "reload" for subsequent re-try attempts.

Does cache: "reload" keep item cached after 404 or integrity failure ?