Docs: Update cache status descriptions and examples for async stale-while-revalidate

src/content/docs/cache/concepts/cache-control.mdx

@@ -138,7 +138,7 @@
 | `Private=<headers>`       | Will not cache.                                   | Does not cache `<headers>` values mentioned in `Private=<headers>` directive.                                                                   |
 | `must-revalidate`         | Cache directive is ignored and stale is served.   | Does not serve stale. Must revalidate for CDN and for browser.                                                                                  |
 | `proxy-revalidate`        | Cache directive is ignored and stale is served.   | Does not serve stale. Must revalidate for CDN but not for browser.                                                                              |
 | `no-transform`            | May (un)Gzip, Polish, email filter, etc.          | Does not transform body.                                                                                                                        |
 | `s-maxage=delta, delta>1` | Same as `max-age`.                                | `Max-age` and `proxy-revalidate`.                                                                                                               |
 | `immutable`               | Not proxied downstream.                           | Proxied downstream. Browser facing, does not impact caching proxies.                                                                            |
 | `no-store`                | Will not cache.                                   | Will not cache.                                                                                                                                  |
@@ -294,7 +294,7 @@
 
 `Cache-Control: max-age=600, stale-while-revalidate=30`
 
-This configuration indicates the asset is fresh for 600 seconds. The asset can be served stale for up to an additional 30 seconds to parallel requests for the same resource while the initial synchronous revalidation is attempted.
+This configuration indicates the asset is fresh for 600 seconds. The asset can be served stale for up to an additional 30 seconds while Cloudflare revalidates the asset with the origin in the background. For more information, refer to [Revalidation](/cache/concepts/revalidation/).
 
 
 </Details>

src/content/docs/cache/concepts/cache-responses.mdx

@@ -51,11 +51,13 @@ The origin web server instructed Cloudflare to bypass cache via a `Cache-Control
 
 ## REVALIDATED
 
-The resource is served from Cloudflare's cache but is stale. The resource was revalidated by either an `If-Modified-Since` header or an `If-None-Match` header.
+The origin confirmed the cached resource was unchanged via a conditional request (`If-Modified-Since` or `If-None-Match`), and the response is served from Cloudflare's cache. This status reflects the synchronous validation path — the request waits for the origin to respond before being served.
+
+With [asynchronous `stale-while-revalidate`](/cache/concepts/revalidation/#asynchronous-revalidation), most revalidations now return `UPDATING` or `HIT` instead. `REVALIDATED` is seen in the following situations: `stale-while-revalidate` is not set; directives like `must-revalidate` or `no-cache` (with [Origin Cache Control](/cache/concepts/cache-control/) enabled) prevent stale content from being served; or the zone is an Enterprise zone that has not yet been migrated (refer to [Synchronous revalidation](/cache/concepts/revalidation/#synchronous-revalidation-legacy)).
 
 ## UPDATING
 
-The resource was served from Cloudflare's cache and was expired, but the origin web server is updating the resource. `UPDATING` is typically only seen for very popular cached resources.
+The resource was expired but served from Cloudflare's cache while the origin updates it in the background. `UPDATING` is the expected status during [asynchronous `stale-while-revalidate`](/cache/concepts/revalidation/#asynchronous-revalidation) revalidation — all requests during the revalidation window receive `UPDATING` or `HIT` rather than waiting for the origin.
 
 ## DYNAMIC
 

src/content/docs/cache/concepts/retention-vs-freshness.mdx

@@ -18,4 +18,4 @@ The time window that an object should be considered safe for a cache to use is d
 
 * Use [Cache Rules](/cache/how-to/cache-rules/) or [Workers](/cache/interaction-cloudflare-products/workers/).
 
-If an object in cache is no longer fresh and Cloudflare receives a request for it, we ask the origin to revalidate the object we have in cache. The Origin can then either send a new version of the object which will replace the old in cache, or tell us the object we have is valid and to refresh its TTL. This revalidation will happen any time an object’s retention period is greater than its freshness period.
+If an object in cache is no longer fresh, Cloudflare revalidates it with the origin. When [`stale-while-revalidate`](/cache/concepts/cache-control/#revalidation) is set, revalidation happens asynchronously at expiry — visitors continue to be served from cache while Cloudflare fetches a fresh copy in the background. Without this directive, incoming requests wait for the origin to respond before receiving content. The origin can either confirm the cached object is still valid (refreshing its TTL) or return a new version to replace it. Refer to [Revalidation](/cache/concepts/revalidation/) for details.