Which cache-busting strategy reliably recovers a Blazor WebAssembly app from a failed deployment?

I'm planning the rollback and recovery story for a Blazor WebAssembly application (targeting .NET 8) where a failed or partial upgrade can leave the browser holding stale framework and application assemblies. The goal is to let the client recover on its own after a corrected redeploy, without asking users to clear their browser cache manually.

My understanding is that the default project template does not ship with a standardized version-invalidation mechanism, so developers typically add query-string cache-busting, customize the service worker (for published PWA assets), or implement their own NavigationManager logic to force a reload when a version mismatch is detected. I'm unsure which of these is dependable across browsers, since private/incognito modes and aggressive HTTP caching can retain old .dll files even after a hard refresh.

On the Blazor Server side, I also assume a circuit that disconnects mid-upgrade cannot resynchronize state across version boundaries, so recovery there effectively means a client reconnect and possibly a host restart, with in-memory circuit state lost. Is that assumption correct for .NET 8's reconnection heuristics?

Specifically: which documented mechanism (service worker update flow, assembly version check plus forced reload, or something else) is the most reliable trigger for discarding stale assemblies? Can the client detect a version mismatch itself, or must the server signal it? And how should this be verified in the Network tab beyond checking the requested .dll versions?