Sanity GROQ CDN cache behavior under concurrent identical requests and rate-limit limits

Sanity serves read queries through an edge CDN at api.cdn.sanity.io, which caches GROQ results according to a configurable staleness window. Public documentation describes the staleness parameter and Cache-Control headers, but does not state whether the CDN coalesces or deduplicates concurrent identical cache misses before contacting the Content Lake origin.

When many clients request the same uncached or expired query simultaneously, each request may independently trigger an origin fetch, increasing latency and consuming per-project rate-limit budget. Because rate-limit thresholds vary by plan and are not fixed constants, teams must decide whether to accept potential HTTP 429 responses or to serialize traffic through their own application layer.

Using staleness=0 forces fresh validation rather than serving stale cached content, which may increase origin contact frequency under load. The interaction between staleness validation, undocumented coalescing behavior, and plan-specific rate limits remains unclear without empirical testing.

Does the Sanity CDN perform request coalescing for concurrent identical queries? If not, what observable headers or response patterns distinguish an origin fetch from a cached validation? How should applications balance staleness=0 freshness requirements against concurrent origin load and per-project rate limits?