Sanity useCdn true vs false for a read-after-publish content page

We run a Next.js front end backed by Sanity (assume a recent @sanity/client major; exact version semantics to be confirmed against its changelog). One concrete constraint: after an editor publishes an update, the public article page is revalidated and re-fetched within seconds, and readers should not see the pre-publish version.

The client exposes the documented useCdn flag. With useCdn: true, reads come from the apicdn.sanity.io edge cache, which is faster and cheaper under traffic but can serve a stale document for a short propagation window after a mutation. With useCdn: false, queries hit the live origin and return the freshest committed content at higher latency and load. There does not appear to be a documented maximum staleness bound for the CDN, which makes the choice hard to reason about for this read-after-publish path.

A split setup (CDN for anonymous traffic, live origin for preview/drafts) is a documented pattern, but our case sits in between: it is a public page, yet freshness matters immediately after publish.

Specifically:

• For a public page revalidated right after publish, is bypassing the CDN the only reliable option, or is the CDN staleness window small enough in practice to accept?
• Can client.listen or webhooks replace the freshness guesswork here, and how would that interact with CDN-cached reads?
• Is per-query client configuration the intended way to mix both modes in one app?