Service Worker stuck in waiting state blocks zero-downtime front-end migration

When migrating a small web application to a new front-end build, the goal is to deliver updated assets to active Firefox tabs without forcing a reload or introducing inconsistent state. Firefox keeps a newly installed Service Worker in the waiting state until every page controlled by the previous worker is closed, which can leave users on stale code even after a successful deployment.

Calling self.skipWaiting() during the install event forces immediate activation, but this may expose race conditions if the new worker assumes resources that the old worker is still fetching. Under cache-first strategies, a mismatch between cached assets and the new worker's expectations can also cause silent failures unless cache names are versioned. These concerns are compounded when server-side API contracts change, because backward compatibility must be maintained independently of the worker update.

Given these competing constraints, what is the safest activation strategy for a small application that cannot afford downtime or stale UI state? Specifically: should skipWaiting() be paired with a versioned cache cleanup phase, or does that introduce its own window of inconsistency? How can developers verify that no tab is still fetching legacy assets when the new worker activates? Is there a documented Firefox behavior that guarantees safe handoff between workers without requiring all tabs to close?